I published a small web application with WCF services locally by using a File System in Visual Studio Community 2017. I hosted it locally to test it and I noticed that a single WCF service was not called and raised a System.BadImageFormatException. The reason was a single id variable from a method of Int32 type.
The solution platform in the Configuration Manager, is a "Mixed Platforms" with Any CPU. So the problem was not there.
I followed the solution by bluwater2001, here by enabling 32 bit applications in the Application pool. However my question remains: Why a 32-bit variable caused such an error whereas my web app was built for any cpu and mixed platforms? And why was it necessary to enable 32-bit applications in the application pool in IIS?
This has nothing to do with the type of your variables/parameters.
If you choose AnyCPU your code can run on any platform. It will compile into 32bit code on a 32bit machine and into 64bit code on 64bit machine.
If your assembly is running as a 32bit process it cannot load a 64bit assembly and vice versa. If it tries to load a assembly which doesn't match the process you get a BadImageFormatException.
Related
Our primary business application is written in a mixture of VB.NET and C# using VS2008. The back-end is SQL server Express 2005.
The application is NOT installed on client machines. It resides on a network share on (currently) a Windows Server 2003 machine which also hosts the database. Clients access the application through a shortcut, and there are additional server-side executables running as services which are accessed by the client application code. It's an entirely 32-bit environment at present.
We are moving to Server 2008 R2 and SQL Express 2008, and will be upgrading some of our 32-bit Win7 clients to 64-bit. I have set the Target CPU to "Any CPU" in the compile options of all .EXE and .DLL projects that comprise the application and have run PVerify on them all - they are entirely managed code.
Is this enough? Will both 32 and 64-bit clients be able to run the application seamlessly?
Thanks
The client applications should work in this configuration, assuming they are pure managed code as you say. You haven't said whether you've tested this or not, but testing shouldn't be all that hard. :-)
Note that 64-bit versions of Windows have the WoW64 subsystem that can run 32-bit applications, so you probably didn't have to do anything in the first place.
The question What does the Visual Studio “Any CPU” target mean? may be worth reading, but it looks like that is already understood here. If you need to be able to produce both x86 and x64 outputs (for example, if you have unmanaged DLLs that need to be called into), the question Targeting both 32bit and 64bit with Visual Studio in same solution/project may be useful.
I've created a very simple console app in .NET 4.0 that will run as a scheduled task. It looks for local files that are unmodified for a certain amount of time and then parses the file, inserts a record into a MySQL database, and copies the file to the network. I'm using a local SQLite database to track which files have already been processed, but unfortunately I'm running into a problem on one system at the first SQLite operation:
System.BadImageFormatException: Could not load file or assembly 'System.Data.SQLite.dll' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1) File name: 'System.Data.SQLite.dll'
at FileDatabase.CreateDatabaseAndTable()
at Program.Main(String[] args)
This exception is thrown on one system (Windows 7 x64 Home Premium with .NET 4.0 full), but is not thrown on two other systems (dev system + one other, both Windows 7 x64 Professional with .NET 4.0 full).
From browsing other questions, I see that this can happen when the program is run in 64-bit mode since the SQLite DLL is the 32-bit version. The first thing I checked is that the active platform is x86 in the Visual Studio Configuration Manager. I also used IL DASM to verify that the output exe is 32-bit (.corflags 0x00000003 // ILONLY 32BITREQUIRED). I would prefer to keep the 32-bit SQLite DLL and target platform as x86 so that I do not have to make different versions of the application for 32- and 64-bit computers.
I've also read that this exception can occur because of a corrupted DLL file, but since it works on some computers, I think this is not the case.
Other things I've tried on the problem system that didn't help:
Searching the GAC and Windows directory for errant SQLite DLLs, but found none.
Turning off AVG anti-virus.
Running the exe directly instead of the published ClickOnce application.
Uninstalling and reinstalling the ClickOnce application.
Any suggestions would be appreciated - thanks!
Installing the full setup package from system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki seems to have solved the problem - it must have been some dependency that was not present (possibly in Windows 7 Professional but not Home?). While this solution isn't perfect for a big deployment, I really just needed it on this one computer. Thanks for RoadBump for getting me on the right path.
I developed an application (C# Framework 4) using the fdf toolkit running on a 32 bit server and everything works well.
I have migrated this application to a Windows Server 2008 SP2 64 Bits and sometimes this application gives me this error:
System.Runtime.InteropServices.COMException (0x800703FA): Retrieving
the COM class factory for component with CLSID
{CB830891-2E18-11D1-B8CF-00A0C9259304} failed due to the following
error: 800703fa Illegal operation attempted on a registry key that has
been marked for deletion.
After this error, I recycle the website pool and the application runs well again.
Details of the application:
Registered the libraries FDF.dll, FDFACX.dll and FDFTK.dll in c:\windows\SysWOW64.
Enabled in the web site pool the property 'Enable 32-Bit Applications'
Enabled 'Do not forcefully unload the user registry at user logoff ' property in the Group Policy Editor
Could you help me?
Thanks¡¡¡
What is the target platform you are building your application for? It will be either x86, x64, Itanium, or most likely "Any CPU".
You can try setting it to x86, that way you know everything is built to use the 32-bit version of .Net. Alternatively you can run CorFlags on your assembly(ies) to change it to x86 without recompiling.
If that doesn't solve the problem then we will need more code :)
I've looked at similar questions on SO, but nothing quite matches my issue as far as I can tell.
The exception message:
Could not load file or assembly 'CrystalDecisions.ReportAppServer.ClientDoc, Version=13.0.2000.0, Culture=neutral, PublicKeyToken=692fbea5521e1304' or one of its dependencies. The system cannot find the file specified.
The file is in my GAC. I am developing on a 32 bit machine (Windows 7) running VS2010, everything is .NET4. The target hosting machine is 64-bit Win 2008 R2. My local machine has the CR installation for VS2010; the hosting machine has the 64-bit runtimes for VS2010. I am compiling all my code in "Any CPU" mode for this web application.
It is blowing my mind that it cannot find the file in the GAC. This is an IIS application; is there some sort of permissions issue? I would think IIS would have access to the GAC.
Some suggestions of what to do would be appreciated.
It turns out the answer was ridiculously simple, but mystifying as to why it was necessary.
In the IIS Manager on the server, I set the application pool for my web application to not allow 32-bit assemblies.
It seems it assumes, on a 64-bit system, that you must want the 32 bit assembly. Bizarre.
1) Change your .net profile from Client profile to to .Net Framework 4.0
http://msdn.microsoft.com/en-us/library/bb398202.aspx
2) Check your Embed Interop Types flag
http://weblogs.asp.net/cazzu/archive/2011/03/11/check-your-embed-interop-types-flag-when-doing-visual-studio-extensibility-work.aspx
Regarding the 64-bit system wanting 32-bit support. I don't find it so bizarre:
Although deployed to a 64-bit system, this doesn't mean all the referenced assemblies are necessarily 64-bit Crystal Reports assemblies. Further to that, the Crystal Reports assemblies are largely just wrappers to a collection of legacy DLLs upon which they are based. Many 32-bit DLLs are required by the primarily referenced assembly. The error message "can not load the assembly" involves these DLLs as well. To see visually what those are, go to www.dependencywalker.com and run 'Depends' on the assembly in question, directly on that IIS server.
You simply need to install Crystal Report Report Run Time downloads on Deployment Server. If problem still appears, then place check asp_client folder in your project main folder.
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.