My .net 4.5 project is referencing a nuget package (System.ValueTuple 4.3.0, targeting .netstandard).
The code is obfuscated using SmartAssembly 6.10 (I'm aware this version doesn't support .NET Standard).
The program works fine on a machine running .NET 4.7.1.
The program fails on a machine running .NET 4.5.2 when Value Tuple code is reached with:
System.InvalidProgramException: Common Language Runtime detected an invalid program
I understand why this fails on 4.5.2 but it's unclear why it's working on 4.7.1. If my version of SmartAssembly doesn't support .NET Standard I'd expect to see the exception on both machines, regardless of .NET version.
Needless to say, when SmartAssembly is not used the program works fine on both machines.
Grateful for your thoughts.
I asked the same question in the SA Support forum and got an answer which basically says ".NET standard is a weird creature".
Not marking this as the accepted answer obviously, but it's all we've got at the moment.
Related
There appear to be two NuGet packages to use async/await in Silverlight applications. I've used
http://nuget.org/packages/Microsoft.CompilerServices.AsyncTargetingPack
so far, but this didn't show up in the search anymore. Instead I found
http://nuget.org/packages/Microsoft.Bcl.Async/
However, both are last changed at the same date (4/18/2013) and none refers to the other in the description. I'm tempted to believe that the latter supersedes the former, but I'm not sure.
My question is specifically how these packages relate to each other and more generally if there's some documentation / principles about nuget releases that I should be aware of to make sense of this by myself (eg: is it typical to supersede on package with another, where is this documented, etc.).
Microsoft.Bcl.Async is a replacement for Microsoft.CompilerServices.AsyncTargetingPack.
It is not typical to supersede one package with another on NuGet unless you change its name. In this particular case, I believe AsyncTargetingPack was (incorrectly) listed without the "prerelease" flag, and then the team at Microsoft took a wider approach (supporting more scenarios) in Bcl.Async.
Bcl.Async in my mind superseded AsyncTargetingPack when it was first (pre)released several months ago, but there was some confusion for two reasons: 1) The team still referred to Bcl.Async as the "async targeting pack", and 2) The Bcl.Async package was (correctly) listed as prerelease, so for many devs only the AsyncTargetingPack would show up in NuGet searches.
Again, this is all speculation, but I suspect the Microsoft team decided to leave things as they were rather than break backwards compatibility for devs who were already using AsyncTargetingPack.
Now that Bcl.Async is at a final release, they can (and did) go back and correct the AsyncTargetingPack/Bcl.Async mixup so that both existing and new devs can easily find the correct package.
I am on Windows XP with VS2010 and .NET 4.0 with Async CTP and other extensions for C# 5.0
Here is my post how I get/use extensions for C# 5.0 in .NET 4.0, which (.NET 4.0 on machine without installed .NET 4.5) is different from .NET 4.0 on machine with installed .NET 4.5
I do not use NuGet since it always brings packs either for .NET 4.5 (with descriptions for .NET 4.0) or for .NET 4.0 which do not work in .NET 4.0 without .NET 4.5 installed
Related posts:
My answer to question "Asynchronous Programming with Async and Await"
My question "Equivalence or conversion matrix between .NET 4.0 Async CTP terms and their .NET 4.5 analogs?"
I have a Winforms .NET program and use a property grid to edit the DefaultCellStyle. This works on my development box but I have a test running under VMware and for some reason on this machine it is read only. But, I have ran it under other machines and not seen this before.
I am copying the executable and thus the code and all properties are exactly the same.
I have found the answer. The new machine only had .NET 4.0 but not .NET 4.5 installed. When I installed .NET 4.5 then it worked even though it didn't require .NET 4.5 to run. This was the only "side effect" I seen. Very peculiar.
I'm trying to compile a simple 32-bit Hello World application written in C using Visual Studio 2010 on a 64-bit machine on a Windows 7 fresh install. I also installed the "Windows SDK for Windows 7 and .NET Framework 4" after installing Visual Studio.
I built the application selecting "Win32" as platform. It works on Windows 7 but if I run the application on my 32-bit machine with Windows XP Professional (fresh install also this, without softwares and Service Packs) it seems not working getting this error:
"This application has failed to start because msvcr100.dll was not found"
If it can be useful Dependency Walker detects 2 errors (see the linked picture for details):
"Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module."
"Error: Modules with different CPU types were found."
http://img820.imageshack.us/img820/4725/errordp.png (PIcture)
How can I solve it? Thanks!
The machine on which it is run needs the runtime libraries. See this MSDN information.
Don't trust Dependency Walker on this... It clearly shows your exe is 32 bit. Your problem is with the VC redistributables, which are the CRT dlls - look for vcredist_x86.exe in your VS installation. You should run it before you run your app.
Another option is to statically link the CRT. See the /MT option. Will make your exe larger, but save the vcredist stuff.
The problem here is the C runtime used by the compiled program is missing on the Windows XP machine. Visual Studio 2010 will by default us the 10.0 (msvcr100.dll) runtime which is not available on XP by default. You need to manually deploy the C runtime on your machine in order for your program to run.
You may want to read the following MSDN article which discusses the issues around deploying C applications built with Visual Studio 2010
http://msdn.microsoft.com/en-us/library/zebw5zk9.aspx
There may be additional 32 / 64 issues at work but this appears to be the primary problem
The answers about the runtime library are correct. Another possible solution is to link to the static runtime libraries rather than to the DLL versions. This way you can build an executable that you can drop onto any machine without extra deployment hassles.
It's a trade-off, but, without knowing more about your situation, it might be worth considering.
I have a project that was created with VS2008. I'm trying to build it with MSBuild 4.0, but still targeting the 3.5 framework. When I do so, I get the exception:
[exec] ResGen : error RG0000: Could not load referenced assembly "C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\PresentationUI\v4.0_4.0.0.0__31bf3856ad364e35\PresentationUI.dll". Caught a BadImageFormatException saying "Could not load file or assembly 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\PresentationUI\v4.0_4.0.0.0__31bf3856ad364e35\PresentationUI.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.".
Note that it's trying to load the 4.0 version of PresentationUI.dll, even though I'm compiling for the 3.5 framework. It doesn't matter if I convert the project to VS2010 format or not, the error is the same.
The problem turned out to be that the HintPath of the PresentationUI.dll assembly didn't match the actual assembly location. In that case, MSBuild falls back to looking for the assembly in the GAC. Since MSBuild 4.0 runs on the .NET 4.0 runtime, it picks up the 4.0 version of the assembly, which is incompatible with the 3.5 project being compiled.
I Got the same problem and while looking for the solution in stackoverflow came across this question.Finally after R&D I got the solution.
Remove the old references and add new ones (If any).Go to advanced Compiler option and Select Target Framework as 4.0. :) It worked Enjoy.
One more reason for this Exception is the mismatch of Target Platform among all the Projects in the solution. For example, if a few projects have Target Platform as x86 and the rest have x64 then you will get this exception.
I have an application, which I develop in VS 2008 and I target .NET 3.
Unfortunately when I install on a clean computer with .NET 3, it crashes. And besides the usual TypeInitilisationError, I have no clue why.
Updating the same machine to .NET 3.5SP1 makes it run fine.
Is there something broken in VS2008 that prevents from telling me a more detailed error?
How can I be sure I don't use any of the newest classes of the framework?
It is true that I found myself using DropShadowEffect which belongs to 3SP1. I removed it.
But still...it does not work.
What am I doing wrong?
Have you tried to determine which version of the framework is installed on each computer. If you're using .Net 3.5 SP1 to compile the program it actually includes .Net 3.0 sp2 which has some extra features (MultiSelector class to name one) which are not available in .Net 3.0 sp1 which is the default install with .Net 3.0 download from Microsoft.
You can try here for some software that will help:
NetVersionCheck
EDIT:
Visual Studio won't tell you about any errors for this because everything seems fine with the version of .Net 3.0 that it's using. I ran into this problem using the WPF toolkit as it requires the MultiSelector class which didn't arrive until .Net 3.0 sp2. So, Jonathan, if you can show us the error output from your program on the 'Fresh' .Net 3.0 computer then we could probably tell you what you're using that is in .Net 3.0 sp2 that isn't supported in lower versions.
Also, I usually use VS2005 with programs that I want to run under a lower runtime than .Net 3.5sp1, but this really only applies to .Net 2.0 apps.
If we knew what components from .Net 3.0 that you're using, it would help as well!
Noah
Thanks for the answer.
Because of VS2008, on my dev computer i have the latest 3.5SP1.
But in Visual Studio i selected 3 as a target.
And to check i install on a clean computer with 3.0...
So your proposition do tells me which framework is installed, but does not tell me what in my program uses in the newest framework that is not present in 3.0.
Moreover, something must be broken in VS2008 as it should warm me for that...
I feel like this is a problem with VS 2008, but obviously MS feels differently.
VS 2008 comes with .NET 3.5, some .NET 3.0 service pack, and .NET 2.0 SP1. It can only detect whether you are using things that don't belong to a version that is installed on your machine, not whether you are conforming to some service pack. This means that if you target .NET 2.0, but install your software on a machine that does not have .NET 2.0 SP1, if you use anything specific to SP1 your application will fail when it tries to make the call.
The only way to detect this that I have seen is to inspect the changelist of the service packs or to target .NET 3.5. If .NET 3.5 is installed, so are the service packs that come with it. It's not a good solution, but it's the only one I've found.