I made a default Silverlight 5 project in VS2013 and let Visual Sudio create the sample web host as a web application. I then ran it and saw that it loaded fine.
Now things get odd: I want to call some C++ code (cryptopp) so I think that I need Silverlight to run as x86 to include it. When I swap it to build as x86 and run the app in the browser it crashes (not calling anything yet, only swapping the debug build configuration to x86).
So: Is it even possible to run Silverlight as x86?
Edit:
64 bit OS. 32bit and 64bit IE both fail to display
Your only chance to call a lib written in C++ (and therefore unmanaged code) is to run your silverlight app with elevated trust.
You did not mention that you configured it to require elevated trust, so maybe that's where your actual problem lies? I don't think it has anything to do with x86 vs x64.
The answer is apparently no.
No you cannot run a Silverlight app that has been compiled as x86. It fails to initialize.
It appears to have a hard time loading an assembly that is required for a base, empty Silverlight app. We've verified it on 3 machines in both Silverlight 4 and 5.
Related
I have compiled a c natives 32bit DLL with Dev-C++, create the reference on my asp.net project, write a dllImport directives and use my new DLL. When launch my DEBUG session all work very well but when deploy my project on Web Server the runtime not load my DLL.
My IIS 7.0 w3wp.exe runs as a 64 bit process (to check if your process running as a 32 bit process under WOW64, open the task manager's Process tab and see if the process name contains "*32").
I believe that a 64 bit process can only load 64 bit native DLLs (and managed DLLs built for "Any CPU" or "X64"). Perhaps your debug session is a 32 bit session? If this is the cause, take a look at Using a 32bit or 64bit dll in C# DllImport .
For those of you who still cannot find a proper way to use a 32-bit DLL under a 64-bit IIS Application Pool, either by tweaking the registry, or by trying how to deal with the "COM+ Components Services", I have found a perfectly working solution : "Encapsulating" the 32-bit component into a new COM object as described on this page did the job perfectly, and I think that a lot of you will be interested to solve the problem this way ;)
http://www.chestysoft.com/component-services.asp
In my case, that allowed me to use the "XStandard.Zip" free Component from XStandard, which is sadly only available as a 32-bit ASP component, and that have an "InProcServer32" Key in the registry apparently preventing it to work by tweaking the registry, as described here : https://techtalk.gfi.com/32bit-object-64bit-environment/
In this post, a lot of comments reported that "InProcServer32-IDs are not reflected because Microsoft assumes that these are only InProc-Calls and not Out-Of-Proc-Calls".
And that was my case too, leading me to the situation where the registry tweaking solution described in the previous post was not working in my case, as other users.
Hoping having saved some days... or nights !
I'm developing an application that uses a plugin mechanism to load libraries. Usually the hosting application runs as 64bit application.
So far everything worked as expected. x64 assemblies could be loaded, AnyCPU could be loaded and x86 assemblies failed. That is - until someone came up with the idea and created an x86 Console Application - and it could be loaded as well.
Why is it possible to load an x86 console application assembly (exe) from a 64bit host process, but it fails to load an x86 library (dll)? Just for clarification - I'm not trying to load x86 dll's and not intend to - just curious why it's allowed to load x86 applications.
(If anyone is interested I can attach the sample code that I used)
The response to this was given in Microsoft Connect some time ago... however I can't seem to find the link.
I did, however, find a thread where they reference it with the response here.
Quoting:
Hi. Thank you for reporting the issue. It looks like you stumbled on an implementation detail - we do not use LoadLibrary for executables and it looks like in this case it does a validation that we do not. I cannot say this difference was the intended behavior, however if we were to to add an additional check now we could break someone, and the issue does not seem serious enough to take the risk.
Here is a link to a sample application which reproduces the error:
http://sdrv.ms/17j2Ale
I have three projects. One is a .NET 2.0 Windows Forms application (.NET App), one is a VB6 Standard EXE application (VB App), and the other is a VB6 ActiveX DLL (VB DLL). The .NET App references the VB DLL which is already registered. This VB DLL essentially launches Crystal Reports. The VB App launches the .NET App via the Shell() command. Here's what happens:
If I run the .NET App directly, I can open a Crystal Reports document with no problem. However, when the VB App launches the .NET App via the Shell() command, when the .NET App attempts to open the Crystal Reports document, I get an Out of Memory error.
Now here's the kicker - this worked on Windows XP, but when we attempt to launch it in Windows 7 64-bit, we run into this issue. I'm sure there's got to be a simple solution out there for it. Any takers?
You can jump to Update 5 where I narrowed down the problem.
Update: I also tried creating a second .NET 2.0 Windows Forms application (.NET Launcher), and launched the .NET App from it via:
Process.Start(#"C:\Path\OtherApp.exe");
and when I tried open the Crystal Reports document in the .NET App it still gave me the same Out of Memory error.
Update 2: removed due to update 4
Update 3: So today I discovered that the reason the .NET App was able to open the report when it was launched directly was because I was launching it within Visual Studio. When I tried the executable outside Visual Studio, the error returns. I noticed that Visual Studio, as of 2005, began using a vshost.exe to launch windows applications to speed up debugging startup: http://blogs.msdn.com/b/dtemp/archive/2004/08/17/215764.aspx
When I disabled the vshost feature, the out of memory error returned. So I suppose the question is, what is this vshost process doing that allows it to work on windows 7?
Update 4: I was able to compile the VB6 DLL with debug information and load the source and debug information into Visual Studio and step through it when the .NET app executes the VB6 code. The Out of Memory exception comes from this line:
Dim myForm As frmTheForm
Set myForm = New frmTheForm 'OOM Error right here
So inside the vshost.exe this form is able to initialize but not without it.
Update 5: I have narrowed down the problem to the Crystal Reports ActiveX Viewer. I started a new VB ActiveX DLL project from scratch and started with only a form. This worked every which way. Then I added the Crystal ActiveX Report Viewer Library 11.5 - and the error returned! It is definitely the Report Viewer. I'm told that this problem may be able to be fixed by a simple registry adjustment.
Update 6: I used Procmon.exe from Sysinternals and generated a logfile that can be found here:
http://sdrv.ms/194aO7A
I've got such problems when I use 32Bit C/C++-Dll's with .NET code running on 64Bit Windows.
If your .NET project has "any platform" as target then the runtime compiles the code to 64Bit on a 64Bit Windows, on a 32Bit Windows I think you'll have no problems.
You have to set your target platform to "x86", you wrote you did this. Please verify that all your .NET projects in your .NET solution are set to x86 as target.
The Crystal Reports *.dll should be a 32Bit COM *.dll, and the VB6 *.dll too.
I found a workaround solution to the out-of-memory error; however, it is not an allowable solution. Apparently, this issue is resolved in future versions of the crviewer.dll but Mister Uher makes it very clear in his response to my question here: http://scn.sap.com/thread/3405856 that we are not allowed to use the versions after 11.5 due to licensing restrictions. It would seem this is a common question he receives. Unfortunately, we are forced to accept the response that we are to upgrade our applications to .NET. If anyone else is feeling adventurous enough to attempt to troubleshoot the out-of-memory exception, I would am happy to leave my sample project above available to anyone who wishes to venture it. Best of luck to anyone else feeling my pain of CR 11.5 interop support.
Not sure if this information will help, but I have faced similar problems in the past with crystal and a Web Forms applications. I resolved it by ensuring that the application pool has the 'Enable 32 bit applications' option checked? You can find it under the advanced settings -> General....
I am developing a 32bit WinForm app (target: .NET 3.5). My client insists the app be installed into "Windows\System32\clientname" folder and autostarts on startup. Also, the app must be 32bit, so I can't use "Any CPU".
I am developing under Win7 x64 with VS2010 and all versions of .NET are installed. When I start the app I get the message "Unable to find a version of runtime to run this application".
On Win7 x86 it works without problem. It's not the app itself and I am 100% sure all the required frameworks are installed.
I know that on a x64 system this folder is not to be used for 32bit apps but as I said: client insists and won't budge.
Before I tell client definitively that it can't be done I want to explore all options. I googled of course and also searched this fine site but nothing helpful for my particular situation came up.
My app spawns another 32bit process located in the same folder. On x64 that didn't work either, of course, but I solved that by using "Wow64DisableWow64FsRedirection" and then copying it to another location to start it from there (which works fine).
I have done my homework but I just can't find a solution for starting the main app under x64 and in that particular folder.
Is there one?
In an attempt to solve this problem I created two folders on my Win7 x64 machine:
C:\Windows\System32\ClientName; and
C:\Windows\SysWOW64\ClientName
Next I created a simple x86 WinForms application targeting .NET 3.5. I found that if I copied the executable to C:\Windows\System32\ClientName I got exactly the same error message as you reported.
However, if I copied the executable to both directories, then I could start it from C:\Windows\System32\ClientName, and it worked just fine.
I did not try this, but I suspect that if you have a multi-assembly application, you only need to copy the *.exe file to C:\Windows\System32\ClientName. All of the other files (and the EXE) would then reside in the C:\Windows\SysWOW64\ClientName directory.
This is a bit of an untidy solution, I know, but then again your client's requirement is a bit unusual to start with.
I made C# application for my friend which has connection to access database (mdb file). I have developed application on my computer with win7 x86 installed. My friend had XP and it worked perfectly, but now he installed win7 x64 and application doesn't work. In fact, application starts and behave regular, but cannot connect to database... Database too can be opened with access, but my application cannot connect to it.
What can be a problem? How to make my application works on both operating systems?
regards,
Vajda
Ask your friend to download and install the following file:
Microsoft Access Database Engine 2010 Redistributable
and make sure he picks the 64-bit version there (AccessDatabaseEngine_x64.exe).
By default there is no 64-bit ODBC/OLEDB driver for Access installed, but the 2010 version should work for 2007 databases as well.
You could probably also configure your program to be built for the x86 target. That would run the program as a 32-bit program, even on 64-bit OS.
Most likely, the .Net CLR is trying to fire the app up in 64bit mode by default on his new win7 box and this might be causing some issues with the referenced assemblies.
The first thing I would try is to change the Platform target of the application (go to Project properties in Visual Studio for the application) to x86 (from Any CPU) to force the application to run in 32bit mode.
If this works, you will have narrowed down your problem.
Then, after building the project, look in the bin folder to see which assemblies are being copied to the output folder. If you see any System.Data... or any other .Net assemblies that are already contained in the GAC, you'll want to delete these and then try to fire it up. This will force the application to use GAC assemblies written for 64bit use.