I have this error repeating continuously in my program.
I have tried the following:
Restart Visual Studio
Clean and Rebuild Solution
When I step through the code line by line, it stops leaving me totally confused at a method call:
GenerateWorksheetPart1Content(WorksheetPart worksheetPart1)
I don't understand why it stops there. The parameter is not null at the point. What could be causing the error?
MSDN - InvalidProgramException
Excerpt:
The exception that is thrown when a program contains invalid Microsoft
intermediate language (MSIL) or metadata. Generally this indicates
a bug in the compiler that generated the program.
This is happening as you step through the code because as your method is called it is being JIT compiled. If the compilation by the JITer is invalid, this exception will be thrown at this point.
Try following-
1) Delete temporary asp.net files from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
2) Recompile the assemblies and update the corresponding referenses
Related
I'm debugging a .NET 4.0 application in Visual Studio 2015. My application builds and runs fine, but when I try to edit and continue while running under the debugger, regardless of what changes I make or where I make them in my main project, I get a dialog that says:
Edits were made which cannot be compiled. Execution cannot continue
until the compiler errors are fixed.
As an example of the sort of change I'm talking about, I've tried adding this line in various methods:
Console.WriteLine("foo");
When I look in Visual Studio's Error List pane, I see only one error, CS7038, with the description "Failed to emit module '<my app name>'." No filename, line number, or character is given. There are no squiggly red underlines in my code. If I stop the running application, build with the changes, and run again, everything builds and runs just fine. So there seems to be some discrepancy between what the build-time compiler and the edit-and-continue compiler consider acceptable.
Does anyone know of a way to get more information about why the compile fails in Edit and Continue mode? I read something about attaching to and debugging the VBCSCompiler process, so I tried that, but even with all exception types set to break when thrown, the attached VS never broke.
I'm not sharing any code because this isn't a question about my code but rather about strategies for finding out what the Edit and Continue compiler thinks is wrong, and for all I know the source of the compiler error could be anywhere in my entire project.
Edit:
As mentioned in the comments, I was able to attach a debugger to Visual Studio and break when an exception was thrown upon clicking "Continue" after editing code. The exception was a System.NotSupportedException with the following message: "Changing the version of an assembly reference is not allowed during debugging". It listed the name of the assembly in question, which was a small VB.Net project used by my application, which is mostly in C#. I'm trying to build up an MCVE to submit to Microsoft, but currently I'm unable to reproduce the problem in a smaller solution with just one VB and one C# project.
Edit 2:
I've found a workaround and self-answered the question in case anyone else ever encounters this weird problem, but I'm reserving the "Answered" check mark for anyone who can explain what's going on (why the compiler thinks the version number of the referenced project has changed during the edit).
I found a workaround for the problem, but I don't fully understand what was going on. In the VB.NET project whose assembly version the Edit and Continue compiler said was changing, there was a file called "AssemblyInfo.vb". That file contained the following line:
<Assembly: AssemblyVersion("3.0.*")>
The assembly version can also be set in the Project Properties, via the "Assembly Information" button in the Application tab:
When I removed the AssemblyVersion line from AssemblyInfo.vb, my Edit and Continue problem went away. At first I thought this was because the fields in the Assembly Information window were saved to a different file from AssemblyInfo.vb and there was some conflict between the two, but now I see that the Assembly Information window is just a handy way to edit AssemblyInfo.vb: if I delete the line in AssemblyInfo.vb, it gets cleared in the Assembly Information window.
After some more experimentation, it appears that the asterisk in the version number is the culprit. If I fully specify the assembly version, my Edit and Continue problem goes away. And the referenced project has to be a VB.NET project. I tried the same setup with a C# project, and I could Edit and Continue just fine.
This appears to be very much an edge case, and I'll submit a bug report to Microsoft, but in the meantime I'd love to know what is actually going on with the compiler--why it's getting two different assembly versions of an assembly that really shouldn't need to be recompiled during the debugging.... If you have a good explanation for what's happening, please add it as an answer.
Edit: here's the bug report I filed.
This happened with me in a .net 4.8 app with Visual Studio 2019.
I have a mix vb and cs projects, here the problem appears when a vbproj references a csproj that uses the wildcast operator '*' to specify the version of the assembly.
As commented above by #Wai-Ha-Hee, the wildcast uses the current time, I belive when VS rebuild the application to apply the edits you have made, the version of the assembly changes causing the error.
In assemblyInfo file (of the project present in error) Change:
[assembly: AssemblyVersion("1.0.*")]
To:
[assembly: AssemblyVersion("1.0.0.0")]
It Solved for me.
An important thing to say is the use of wildcast '*' make the assembly non-deterministic, it means each build produces a different assembly. This has been considered bad practice because build the source code in the same conditions generates different assemblies.
In Visual Studio 2019:
New csproj/vbproj with non-sdk style projects file are generated with:
<Deterministic>true</Deterministic>
And new csproj/vbproj with Sdk style projects file omits this line but assumes deterministic as default too.
I recommend considerate other ways to version the assembly.
More about Deterministic:
http://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html
https://reproducible-builds.org/
One of my C# projects in a mixed solution was .NET Framework 2.0 (while others - both C# and VB.NET - were .NET Framework 4). After I changed it to .NET Framework 4 it began to work.
Is there a way to have Visual Studio 2010/2012 skip over certain compiler errors and just keep compiling the rest of the code.
I keep getting this error for DNN and I don't need it.
'ControlName' is not a valid value for attribute 'classname'
No, a compiler error means that there is something fundamentally wrong with your code, such that the compiler is unable to determine what executable code to generate. Syntax and semantics errors must be fixed and cannot be skipped to achieve successful compilation.
Warnings, however, can be skipped or suppressed because they indicate a potential mistake or issue, rather than a blocking one.
I am using sonar code analysis tool for analyzing my c# language projects.. It is working fine for some projects. But for some projects, while uploading in sonar, i am getting Fxcop execution failed with return code '9' or '513' or '12' and saying that execution failure...
Check FxCop documentation about exit codes to know more about those failures: http://msdn.microsoft.com/en-us/library/bb164705%28VS.80%29.aspx
Fxcop error code 9 means that Fxcop analysis was failed for one of the dll or project in the solution.
Sometimes Fxcop Analysis failed for some projects in the solution due to various reasons. One of the reason may be that Fxcop requires some DLLs to complete the analysis. In this case the Fxcop analysis for complete solution gets failed and Fxcop exits with error code 9. This results in failure of complete sonar analysis.
Solution: We can make use of the sonar property sonar.fxcop.assemblies to run Fxcop analysis.Provide the comma separated paths of only those dll as this property value on which we want to run Fxcop analysis.
eg: sonar.fxcop.assemblies=path of dll1,path of dll2
Put this property in the sonar.properties file which resides in the same directory in which solution file lies. Don't provide the path of dll which is causing failure.
Since Fxcop will not do analysis on the problematic dll, the sonar analysis will not exit now with the error message "FxCop execution failed with return code 9 in sonar."
For complete problem reason , analysis and solution click here.
I found a solution to this error by checking the FxCop report file (fxcop-report.xml, in my case it was stored in the .sonar folder, under my projects root folder).
In this file I could to see that the problem was with a rule not being loaded (CA2001) and, then, a object null reference happened.
I changed the FxCop instalation, from my standalone instalation do Visual Studio's instalation. The versions were differente.
Problem solved.
I'm getting an "System.NullReferenceException: Object reference not set to an instance of an object." Error when I launch a release build of my web application. It tells me to do a debug build to get more information, but when I launch the debug build the error no longer occurs. Without the help of the line numbers that are given with most errors in debug builds it is very hard (from what I know) to pinpoint the cause of this vague error.
Can anyone point me in the right direction to narrow down the cause of this exception?
Thanks.
As a quick remedy to your problem (if you don't have time to rewrite your code), please see the Event Log on the machine where you released the application. There is a big chance you're simply missing some dlls.
As a long term solution, I think you can start with adding some logging functionality to your application (Enterprise Library, log4net, etc. or even your own logger). Printing a complete stack trace is an invaluable source of help especially when you include the .pdb files in your release version. This will allow your executed code to tell exactly which line threw the exception.
Hope this helps,
Piotr
It is possible to get file names and line numbers in your stack traces even if you build in Release mode. See Display lines number in Stack Trace for .NET assembly in Release mode and Is stacktrace information available in .NET release mode build? for example.
In general, I think you should avoid introducing different program behavior in Debug versus Release mode (but maybe you didn't introduce that deliberately?).
I have a big and bloated software and I want to add a new GUI element to it. The GUI element was written using XAML and WPF. I created the UI element in a separate assembly, and reference it in the big software. The two projects compiled smoothly under VS2010, but when I run my application I get a TypeLoadException.
Looking into the exception with the debugger, I get the following message : Could not load type GUI.Dashboard from assembly GUI, blah, blah. There is no InnerException nor any further detail.
The .GNU documentation says that this message appears when there is no message passed to the constructor of the exception. I assume that the producer of the exception itself does not know how it happened.
I tried using the tool Fuslogvw.exe and it effectively showed me some minor missing dependencies which are unrelated. However, it cannot find any information on this very exception.
What kind of problem can possibly throw an imprecise exception like this one ? Is there a way to make Fuslogvw.exe aware of it to get some details ?
Thank you in advance,
Edit :
I effectively compiled my application with debugging symbols. The exception happens when I try to instanciate a class containing a reference to the problematic symbol. i.e.:
class SomeClass
{
GUI.Dashboard dashboard;
}
And the call trace looks loke this:
at SomeClass..ctor()
at MainClass.Main() din MainClass.cs:line 42
Possible issues include:
The assembly you reference is x64 only and your consumer is x86 or AnyCPU on a 32-Bit CLR
Your consumer assembly was compiled against a different version of the referenced assembly
You can try to use FusLogVW to turn on assembly binding logging and check the logfile for more information about what failed.
TypeLoadException is thrown when the common language runtime cannot find the assembly, the type within the assembly, or cannot load the type.
TypeLoadException uses the HRESULT COR_E_TYPELOAD, that has the value 0x80131522.
For a list of initial property values for an instance of TypeLoadException, see the TypeLoadException constructors.
Source: MSDN
Just to add another answer to this:
we had a C++ client calling a .NET COM dll.
The developer of the .NET dll renamed the namespace enclosing the C# classes, and although the progid remained the same in both the class attribute and in the C++ calling code, the runtime failed to load the object resulting in this error.
I finally found a reason for this bug : apparently, in some cases referencing a .exe file does not work properly. Some methods and classes loads OK but some fails. In another project, referencing this .exe file cause no problem.
Switching to the .dll format solved all linking problems. I think this is a bug in the CLR.