I'm trying to find out using C# if MSOnline PowerShell module is available at OS.
From the first look - nothing difficult. We can invoke PowerShell methods from C#. But for some reason all code snippets I tried to use do not get result with MSOnline module.
For example we use method http://www.codeproject.com/Articles/18229/How-to-run-PowerShell-scripts-from-C and pass command like:
Get-Module -ListAvailable -Name (here is the name)
So if we run it for TLS module - it works fine. On the picture below we see how it works in C# console application and on the right - how it looks in PowerShell. Looks fair.
But everything changes if we try to lookup MSOnline module:
As we see - C# program gives no results, while PowerShell itself shows us that module is available.
I'm really confused. I thought that is something with my PC, but I have checked on some different ones including Server 2012 R2. Result is the same - this module can not be looked up via C# even if we use exactly the same command as in PS.
Has anyone seen such problem? If yes - what solution can be done to detect via C# if MSOnline PS module is present.
Thank you.
Actually I found a solution for my own question:
You need to make sure that your program and module has both 32 or 64 bits.
MSOnline is running x64 and if your programm is targeting 32 bit system or has Any CPU and runs 32 bits during runtime - you will get zero result.
That's it.
Related
I have a problem with import clr that crashes the .exe of my small program.
Here are the imports I use in my program:
import sys
from matplotlib.figure import Figure
from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as FigureCanvas
from PyQt4.QtGui import QApplication, QMainWindow
from PyQt4.Qt import QGridLayout, QWidget
import clr
executablePath = 'E:\\PythonWS\\MyDll\\'
sys.path.append(executablePath)
clr.AddReference("MyDll")
import MyDll
Basically the program compile fine and I get an executable thanks to cx_freeze, but when I launch it with a log, it crashes when comes import clr
I don't know what to do to make it work, if anyone has an idea?
EDIT:
I added a try-except around the import clr like this:
try:
logger.info('in try')
import clr
executablePath = 'E:\\PythonWS\\MyDll\\'
sys.path.append(executablePath)
clr.AddReference("MyDll")
dllPath = clr.FindAssembly('MyDll')
import MyDll
ts = MyDll.TestSystem('127.0.0.1', '127.0.0.1')
print ts.mainBoard.isConnected()
except Exception as e:
logger.info("Unexpected error: {}".format(e))
But even with the try the appplication crashes... That leads me with 2 options,
either my try except isn't good and then why?
there is a real problem with clr and I need help about it.
EDIT2:
I tried importing other module that are from .pyd thinking it might be that the .exe could not find them but all the import I've tried were done without any problem.
EDIT3:
SO! After looking on other posts, I've seen that there were other ways to import dll: by using ctypes for example.
Problem is: my dll is in C# and apparently the import is not supported very well by ctypes... I got errors like WindowsError: [Error -532462766] Windows Error 0xE0434352 which did not help me much since it seems to be a very general error in windows, but this made me think maybe the thing that makes my program crash when importing clr is the same.. Does anyone know what could the error be related to?
So I am back to using .NET clr, but still no luck
For the record: I have tried both python 32 bits and 64 bits. Here are some more information
#with python 32 bits
platform architecture: ('32bit', 'WindowsPE')
sys.platform: win32
os.name: nt
#with python 64 bits
platform architecture: ('64bit', 'WindowsPE')
sys.platform: win32
os.name: nt
So I eventually made it work:
In the end, pythonNET was installed correctly but it seems the version wasn't the best (not sure if not the latest, or not the right version, or bit), so I deleted every file of pythonNET (that I had copy-pasted here and there to be sure it was seen) and downloaded the .whl (here) of a latest version (which wasn't the one pip was downloading).
And eventually the import clr worked...
I hope this helps some of you :)
Trying to access an old c++ dll from c# using Dll Import.
Been searching around the net for aprox 4 days now without success.
I'm trying to use the c++ dll from an asp.net mvc 3 website .net 4.
I've changed platform target to x86.
I've set "Enable 32 bit application" to true on the application pool in iis.
Using Windows Server 2008 R2 with iis 7.5
Is there some way to debug this or get more info about what might be wrong?
The link ASP.NET P/Invoke "An attempt was made to load a program with an incorrect format" states that:
"To use the 32 bit dll, your web application has to run in 32 bit mode, which is done by switching IIS to run in 32 bit mode" and gives a link about how you can change this, however this seems only to concern IIS 6 and asp.net 2
Thanks in advance!
Best Regards
Edit 1:
Would an erroneous declaration of the c++ method calls in c# result in this error? Reading the error one could guess that calling a function with 3 params that should receive 4 would result in this error.
Well to answer your last question:
Would an erroneous declaration of the C++ method calls in c# result in this error?
No, I don't believe that it would - erroneous declaration of the C++ method could result in a number of things happening ranging from the function executing correctly to an interop exception being thrown, however I don't believe that this exception would be thrown - this is specific to a problem loading the dll.
You should check to make sure that the process attempting to load this dll is actually a 32-bit process by somehow obtaining the process ID (e.g. by catching and logging the exception), and then checking in task manager. If the process is actually a 64-bit process then you may have incorrectly configured something.
You should also check to ensure that the dll you are attempting to load (and all its dependencies) are in fact 32-bit - I believe that you will experience a similar issue if you attempt to load a 64-bit dll into a 32-bit process. You should be able to use Dependency walker (an all-round very useful tool) to check this.
I'm trying to get a third party app (hMailServer) to consume my C# library. They support 3rd party libraries using VBScript hooks. I got everything working fine using registration-full COM, but now want to use registration free.
I've modified the hMailServer.exe manifest and added a manifest to my C# library. Now the hMailServer service starts up just fine and SxS trace shows that the library is found. If I neglect to create my C# library manifest I get an error that "Windows could not start the hMailServer service on Local Computer... because its side by side configuration is incorrect" and sxstrace gives errors so I know the manifests are fine. However, the VBScript events fail to run with the following error:
Script Error: Source(null) - Error:
8013101B - Description(null) - Line: 2
Column: 1 - Code(null)
The first 2 lines of the VB6 script just read:
Dim oHandlers
Set oHandlers = CreateObject("hMailServerPlugins.EventHandlers")
(hMailServerPlugins.EventHandlers is obviously the name of my COM visible class)
As mentioned, everything works just fine with COM registration. Any idea what I'm missing?
This may be a bit late, but I've seen this error if you've mixed .Net framework versions. If you've spun up a CLR of a lesser version first, then attempts to create a C# COM object using a newer framework after the fact will fail with that exception.
We got a DLL written by C# programmers, compiled to usable as COM object.
We consult these developers to get the function names, and syntaxes, and we can use it after we registered it with regasm.
This is ok, but we have more questions to produce faster development (on changes), and some things are not understandable or not working.
We used Delphi 6 professional, and assembly made by C# Visual Studio 2008 (as I think).
Let's see them:
1.)
I cannot use the typelib (TLB) of the C# code, because I cannot import into Delphi.
The result was:
"Hiba az OLE beállításjegyzék használata közben."
Translate ~ "Error occured on use OLE typelib/setting lib"
Possible sources of the error:
a.) Delphi 6 cannot import the new COM dll-s.
b.) We must force to C# generate an older formatted TLB.
We tried to re-generate the TLB with regasm, but we also got this error.
May this impossable, but if case b.) happens, what we need to say to C# developers - how to compile the DLL-s?
(DLL-s are unimportable by Delphi, because they don't have self init section).
2.)
Interesting:
All of the parameters correctly converted into variants vica-versa, but if the C# method does not have parameter, I got error in Delphi side...
For example (pseudo):
proc A():bool;
Calling of A is generating an error in Delphi side.
proc A(Dummy: bool):bool;
Calling of A(False) is working fine.
I don't know, why we got this.
What do you thing about this? Is this a C# compiling problem?
Thanks for your help:
dd
Best route here is to obtain source code showing the successful use of the DLL via COM using, say, C#. The developers of the DLL should be able to provide that. The DLL probably also has to be registered with regasm (not regsvr32.exe as it would be for a native COM DLL) before it will be accessible via COM. As always, without more actual code, it is very difficult to answer such questions.
I have a C# application which links to a few c# DLLs which in turn use bindings to call c++ functions in other Dlls.
This all works fine if I compile the c++ Dlls with /MTd but when I use /MDd I get an XMLParseException in my C# app complaining that it can't find any Dlls(it fails to find the first of my Dlls that I use). My best guess is that using this other switch causes it to change the path where it looks for its Dlls, causing it to fail. I used DependencyWalker to have a closer look and the two Dlls it actually fails to find are 'IESHIMS.DLL' and 'WER.DLL'. I can't see my c# Dlls anywhere in the tree in DependecyWalker however. Anyone have any ideas what might be wrong here?
Also, using the non-debug equivalents (/MD and /MT) make no difference. Regardless, I can't use /MT as it causes another bug.
EDIT: I've narrowed the problem down somewhat. When compiled and linked using the VS2010 command prompt, my app works fine, with the VS2008 command prompt it still fails to find the Dll. Does anyone know any differences between these two version of VS which could cause the behaviour I described above?
Thanks in advance,
Are you compiling all the modules against the same run-time libraries? From:
http://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx
"All modules passed to a given invocation of the linker must have been compiled with the same run-time library compiler option (/MD, /MT, /LD)."