I've been trying to publish a WPF application I've been working on to a specific folder using Microsoft Clickonce. In my application I use the OpenCV wrapper EmguCV. However, when I publish the application and download and install it on a new machine, it gets thrown the following error.
Application: Photo.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.DllNotFoundException
at Emgu.CV.CvInvoke.RedirectError(CvErrorCallback, IntPtr, IntPtr)
at Emgu.CV.CvInvoke..cctor()
Exception Info: System.TypeInitializationException
at Emgu.CV.CvInvoke.cvCreateImageHeader(System.Drawing.Size, Emgu.CV.CvEnum.IplDepth, Int32)
at Emgu.CV.Image`2[[Emgu.CV.Structure.Gray, Emgu.CV, Version=4.6.0.5131, Culture=neutral, PublicKeyToken=7281126722ab4438],[System.Byte, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].AllocateData(Int32, Int32, Int32)
Whats really confusing me though is if I download my bin folder to that same machine and run the application, it works completely fine. Because of this I know the machine is not missing any runtimes, so it would have to be with Clickonce itself. I've verified that I'm targeting x64, and have also checked that all of the EmguCV dll's are being included in the Application Files section of Clickonce. I've also checked EmguCV's documentation about the issue and I've also verified that I have the correct Nuget package with the Emgu.CV.runtime.windows package.
I get BadImageFormatException when running a unit test in VS2013. The error occurs in a call to Assembly.LoadFrom.
Configuration is Debug x64. In this configuration all assemblies are set to build AnyCPU or x64.
TEST | Test Settings | Default Processor Architecture is set to X64.
Wrote a little utility to run CorFlags on each assembly in the test directory. Every assembly is either PE32 (AnyCPU) or PE32+ (x64 only) and no assembly has 32BITREQ or 32BITPREF.
Any idea where this error is coming from?
Situation
I'm using ngen to create native images of my assemblies during the installation. This worked fine until recently and I've no idea what broke it. Sadly the ngen output isn't very helpful. It just says that it couldn't find or load a type, but doesn't say which type.
What's very weird is that ngen only fails if my assembly was build with msbuild (either run by the TFS Team Build or by myself in the command line), but if I build it with Visual Studio 2010 ngen works fine! I've tried msbuild from .NET 4.0 (my local machine), .NET 4.5 (TFS 2012 Update 3) and .NET 4.5.1 (TFS 2013), all result in the same error in ngen. It's just the build in the Visual Studio 2010 GUI that works. But the error only occurs in ngen, runtime behavior is the same - it falls back to the IL assembly, but works fine.
I even tried to debug ngen.exe and mscorsvw.exe, but all I could see was that some native exceptions were thrown, one of them was a EETypeLoadException, but I couldn't get additional information about the exceptions. But I'm not experienced at all when it comes to debug native applications.
Questions
Does anyone know how I could get more information about the ngen error? The name of the type which causes the error would be great.
I've already read somewhere that Visual Studio doesn't just invoke msbuild for building, but why are there that big differences?
Additional Information
The TFS runs msbuild during the automated build. No additional msbuild parameters are configured and the build process template is the default one from TFS 2012 Update 3.
When I run msbuild myself I'm using the following command on the same file and folder that is also used in Visual Studio. Configuration and Platform are also the ones active in Visual Studio and chosen in the TFS Build.
msbuild Solutionname.sln /t:Rebuild /p:Configuration=Release /p:"Platform=Mixed Platforms"
The ngen error happens on all machines that I tested, so it's not something specific to my installation.
Here is the full ngen output, even with the verbose switch:
C:\Program Files (x86)\MyProgram>ngen install MyProgram.exe /verbose
Microsoft (R) CLR Native Image Generator - Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Installing assembly C:\Program Files (x86)\MyProgram\MyProgram.exe
1> Compiling assembly C:\Program Files (x86)\MyProgram\MyProgram.exe (CLR v4.0.30319) ...
1>Error compiling C:\Program Files (x86)\MyProgram\MyProgram.exe: Could not find or load a type. (Exception from HRESULT: 0x80131522)
1> Finished compiling assembly C:\Program Files (x86)\MyProgram\MyProgram.exe ...
1>Ngen failed to generate native code for image C:\Program Files (x86)\MyProgram\MyProgram.exe because of the following error: Could not find or load a type. (Exception from HRESULT: 0x80131522)
1>Ngen will retry compilation of image C:\Program Files (x86)\MyProgram\MyProgram.exe
1> Compiling assembly C:\Program Files (x86)\MyProgram\MyProgram.exe (CLR v4.0.30319) ...
1>Error compiling C:\Program Files (x86)\MyProgram\MyProgram.exe: Could not find or load a type. (Exception from HRESULT: 0x80131522)
1> Finished compiling assembly C:\Program Files (x86)\MyProgram\MyProgram.exe ...
1>Uninstalling assembly C:\Program Files (x86)\MyProgram\MyProgram.exe because of an error during compilation: Could not find or load a type. (Exception from HRESULT: 0x80131522)
Could not find or load a type. (Exception from HRESULT: 0x80131522)
You can use Fuslogvw.exe (Assembly Binding Log Viewer) and take a look at the assemblies ngen is trying to load. That may provide a clue. You may want to capture binding logs for both cases you mentioned (msbuild and VS) and then compare them. I am guessing mbuild is introducing some dependencies not consumable by NGEN.
And when you say runtime behaviour is same, you mean the app is working as it's supposed to ? Then it must be running with IL not the Native Images. Again, you can use Fulogvw to check that.
I'm trying to generate a native image of my .NET 4.0 application using Ngen using a 64-bit Windows 7. When Platform is set to x64 (or Any CPU) - Ngen fails, complaining that 'NGen cannot proceed because Mscorlib.dll does not have a native image.'
When compiling as x86 and using the appropriate Ngen - it works fine. Also, when changing the .NET version to 2.0 - it works. (When trying to Ngen the x64 application with the x86 Ngen, it tells me I should use the 64-bit version.)
More information:
This is (part of) what I see in CMD: The ellipses (= ...) are present in the original.
1> Compiling assembly mscorlib, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089 (CLR v4.0.30319) ...
1>mscorlib, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089
.
2> Compiling assembly Accessibility, Version=4.0.0.0,
Culture=neutral, Public KeyToken=b03f5f7f11d50a3a (CLR v4.0.30319) ...
.
2>Ngen failed to generate native code for image Accessibility,
Version=4.0.0.0,Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
because of the following error: NGen cannot proceed because
Mscorlib.dll does not have a native image (Exception from HRESULT:
0x80131F06)
Searching inside C:\Windows\assembly I found 3 mscorlib.dll's. One in GAC_32, one in GAC_64 (both in subfolders beginning with 2.0.0.0) and one in a subfolder temp.
When searching inside C:\Windows\Microsoft.NET I found six of them: two under assembly (in GAC's 32 and 64) both in folders that begin with 'v4.0...', and four in Framework's: 2 in Framework, and two in Framework64 (in each - one in 'v2.0...' and one in 'v4.0...').
Does this mean that only .NET 2.0 mscorlib's are really run as native images (when needed)? And why doesn't Ngen succeed in saving native images of .NET 4.0?
Bottom line: How do I create a native image of a .NET 4.0 application that targets x64?
This is unhealthy. The ngen-ed image of mscorlib.dll should have been created when .NET was installed on your machine. It is located in c:\windows\assembly\NativeImages_v4.0.30319_64\mscorlib\ab0a8fc3d086a3aaf942f366a12a9185\mscorlib.ni.dll. I'm not sure how well the hashed part of the directory name repeats from one machine to another.
You cannot see this file with Windows Explorer, you must use the command prompt. Go check to see if it there, something went seriously wrong when .NET was installed if it is missing. The ".NET Runtime Optimization Service" is the one that gets that job done, make sure you didn't disable it.
A standard mistake is running ngen.exe from a command prompt that isn't elevated.
I have developed an application using .net 3.5 and have deployed it as an .exe on a number of machines with the same environment.
However, on one particular machine I get the following error. Stack Trace:
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
System.InvalidOperationException: Unable to generate a temporary class (result=1).
error CS2001: Source file 'C:\WINDOWS\TEMP\wz58eig4.0.cs' could not be found
error CS2008: No inputs specified
at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
at System.Xml.Serialization.XmlSerializer.GetSerializersFromCache(XmlMapping[] mappings, Type type)
at System.Xml.Serialization.XmlSerializer.FromMappings(XmlMapping[] mappings, Type type)
at System.Web.Services.Protocols.SoapClientType..ctor(Type type)
at System.Web.Services.Protocols.SoapHttpClientProtocol..ctor()
at SSOClient..ctor()
at sc.tradesvc.SSOManager..ctor()
at sc.tradesvc.SSOManager.get_Inst()
at sc.cashflowgenerator.Controls.LoginForm.btnLogin_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.PerformClick()
at System.Windows.Forms.Form.ProcessDialogKey(Keys keyData)
at System.Windows.Forms.TextBoxBase.ProcessDialogKey(Keys keyData)
at System.Windows.Forms.Control.PreProcessMessage(Message& msg)
at System.Windows.Forms.Control.PreProcessControlMessageInternal(Control target, Message& msg)
at System.Windows.Forms.Application.ThreadContext.PreTranslateMessage(MSG& msg)
Loaded Assemblies:
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
CashflowGenerator
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/DATA/DEVEL/Output/CashflowGenerator.exe
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
System.Core
Assembly Version: 3.5.0.0
Win32 Version: 3.5.21022.8 built by: RTM
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll
System.Web.Services
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Web.Services/2.0.0.0__b03f5f7f11d50a3a/System.Web.Services.dll
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
For example:
When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
Could someone help me with this?
As I am new to .net could someone also tell me when why a temporary class needs to be created in the first place?
I just spent a lot of time searching for the answer to this so I thought I'd add it here to save some headache for others. If you use the xsd.exe tool to generate your cs it may have added double arrays [][] where an array should be []. Replace all [][] with [] in your generated cs file and retry.
XML Serialisation works by generating code to perform the serialisation. This is done in a temporary assembly created for that purpose the first time it is needed.
However this relies on being able to write the assembly to disk.1
Your options are either to (1) given the user account which is running the process write permission (for an ASP.NET application this is likely to be a bad idea). (2) Use the SDK tool (sgen.exe) to pre-generate (at development/compile time) the serialisation assembly, and then use (and deplot) that assembly.
1Open question: the APIs exist to create assemblies dynamically in memory: why not do that?
You only have to give the List Folder Contents and Read permissions on %windir%\Temp.
I found this post when trying to fix my problem, and didn't have to give my user account write access.
From Microsoft
You Need to give the permission to the temp folder which is in windows folder. And Your Problem is Solved...........
You need to add *IIS_IUSR* user with read write permission to C:\Windows\Temp folder.
NOTE: Everyone user will not work with full control.
Surfacing #grzenio's comment a bit further for recent users:
If you go to Project Properties -> Build -> Generate serialization assembly -> On, it forces the generation of the XML serializers assembly at compile time, eliminating the need to do so at runtime.
In turn, this means you don't need to change filesystem permissions (useful if you're, for example, hosting on Windows Azure Web Sites, where that isn't an option).
It may be also just some simple error in the serialized class (typically a result of some copy/paste). For example the following class will cause this error:
public class Foo
{
private string[] contexts;
/// <remarks/>
[System.Xml.Serialization.XmlArrayItemAttribute("Context",
typeof(Property), IsNullable = false)]
public string[] Contexts
{
get { return this.contexts; }
set { this.contexts = value; }
}
}
Notice that typeof(Property) parameter in XmlArrayItem attribute is not compatible (most likely) with string causing similar exception:
System.InvalidOperationException:
Unable to generate a temporary class (result=1).
If typeof(Property) is replaced with typeof(string) serialization will work again.
the APIs exist to create assemblies dynamically in memory: why not do that?
Just a wild guess: I assume this possibility did not exist yet in .NET 1.0, or at least when the XmlSerializer was created and MS doesn't like changing existing behavior...
Give Read/Write Privileges to 'C:\WINDOWS\TEMP' folder. It will work.
It may be bacause you are switching application pooling identity in IIS
to be password instead of predefined
so you have one off the following
return to predefined
give prmission full control to user IWAM_WBSRV-01 on the windows temp folder
In case this helps anyone, my problem was coming from an inherited class used in the serialization. The problem went away when I made a full copy/paste of my class I was serializing and quit using ineritance. Unfortunately, the advantages of inheritance went away, but that is better than having this problem. (Hey, at least I'm pretty sure that's what solved it. Happened to do a reboot in there somehwere too.)
Windows 10 has Virus and threat protection - if you have Ransomware protection (controlled folder access) it will block sgen.exe by default. Add sgen.exe it to exception list.
sgen.exe is located here: C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools
Folder name may vary depending on your Framework version