I am developing desktop application in WPF on .NET Framework 4.0, because of Windows XP on some client computers.
I need async/await in .NET 4.0 so I added references to Microsoft.Bcl.Async (latest NuGet release). Anytime I use Async/Await keyword, program crashes with following exception when started in Windows XP (works in Windows 7+):
Could not load file or assembly 'System.Core, Version=2.0.5.0,
Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes' or
one of its dependencies. The given assembly name or codebase was
invalid. (Exception from HRESULT: 0x80131047)
After extensive research, I found that it is needed to have installed this update in Windows XP in order to Microsoft.Bcl.Async to work.
Related
It looks like System.Data.SqlClient is defined in dnxcore50 when running on Windows, but not on Linux.
Aren't they both corefx?
For example, an app that targets dnxcore50 beta7, or beta8, and references System.Data.SqlClient will build and run fine in Windows, but on Linux will compile fine only to at execution throw this runtime error;
An unhandled exception has occurred: Could not load file or assembly
'System.Data.SqlClient, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
The system cannot find the file specified.
With ASP.NET 5 RC1, SqlClient is now cross platform and so you can query Microsoft SQL Server from Linux and Mac too.
More info in the release notes below (look for Cross-platform SQL Client)
http://blogs.msdn.com/b/webdev/archive/2015/11/18/announcing-asp-net-5-release-candidate-1.aspx
I am using the setup from sqlite.org:
http://system.data.sqlite.org/downloads/1.0.94.0/sqlite-netFx451-setup-bundle-x64-2013-1.0.94.0.exe
Setups for 64-bit Windows (.NET Framework 4.5.1)
My application is set up to use framework 4.5.1.
"Prefer 32 bit" is not checked.
During Debug Mode, it runs flawlessly.
However, when I switch to Release Mode, I am getting this error:
"BindingFailure" detected at "D:\Dev\Projects\MyProject\AppNet\MyApp\MyApp\Release\MyApp.vshost.exe"" festgestellt.
The assembly "System.Data.SQLite" could not be loaded in AppDomain1 in the binding context of "Load":
System.BadImageFormatException: The file or assembly "System.Data.SQLite, Version=1.0.94.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139" or one of its dependencies was not found.
Can somebody tell me how I should do differently?
It seems that my question is a duplicate of
Could not load file or assembly 'System.Data.SQLite'
In this post, there was no real answer but just the suggestion to use x86.
However, I think that this is only a workaround, not a real solution, because the SQLITE binaries are clearly marked 32bit and 64 bit, and I have chose then correct assemblies.
I have problem with my .Net Reflector 8.3 application. When I double click it doesn't start and generates error.
.Net Reflector has just thrown an exception: Could not load file or assembly '{a755eaf2-c07e-4b95-b1ee-a3437dfa4635}', PublicKeyToken=3e56350693f7355e' or one of its dependencies. The system cannot find the file specified.
I am using Windows 8.0 x64. I've also enabled .Net framework 3.5 and 4.5.1 installed on my machine. I've searched every where and find nothing to solve.
Thanks in advance.
We're having the seemingly common error
Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
in a project that needs to be compiled against .Net 4.0 but is built on a build server running Windows Server 2012 (with .Net 4.5). The project is a web application that gets deployed to a web server running 2003, where installing .Net 4.5 isn't an option. There it runs against "classic" .Net 4.0
From similar questions, we're trying command-line options to MSBuild:
/property:FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
We also tried various combinations of
/property:ReferencePath="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
/property:NoStdLib=true
/property:NoCompilerStandardLib=true
The reference assemblies (including the .dll files) are in fact installed in that place on the build server. But when we deploy the website and visit the home page, we get that error. (Interestingly, on a page reload, the error disappears, and the site operates normally.) What are the MSBuild parameters necessary to compile against the .Net 4.0 assemblies?
Update
I turned on ludicrous-level logging on MSBuild, and I see that apparently it is building against the .Net 4.0 reference assemblies:
Resolved file path is "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll
and I didn't see any mention of assemblies outside that folder or the build server's working directory. So it appears to compile properly, but when deployed on the web server, it throws the exception.
As to the exception going away on a page reload, I wonder if that's related to the markup pre-compile step. We're running aspnet_compile on the build server. Maybe if there's an exception coming from a generated assembly, the web server will re-compile it. And the recompiled assembly is fine, because it was created with true .Net 4.0.
Well the answer turned out to be borderline embarrassing. After we confirmed from detailed MSBuild output that it was in fact building the website project against the right reference assemblies, we realized that there are several in-house NuGet packages in the project that had been built against .Net 4.5. One of them was chock full of extension methods, which is what causes the exception. Rebuilding them against .Net 4.0 fixed the problem.
Which brings up an interesting issue. If a 3rd-party NuGet package is compiled for 4.0 but using 4.5 references, we'd be in the same situation, but not able to fix it. So the lesson for package publishers is to ensure your 4.0 version is compiled against the reference assemblies.
I have a project that works great on my machine (and production servers).
It's a VS2010 project running C#3.5.
When letting my build server build the solution it can't resolve a couple of my third party dll's.
Error message:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1360,9):
warning MSB3268: The primary reference
"Third.Party.Assembly,
Version=50.11.2.0, Culture=neutral,
PublicKeyToken=0561a7c6dbd6f0ea,
processorArchitecture=MSIL" could not
be resolved because it has an indirect
dependency on the framework assembly
"Microsoft.VisualBasic.Compatibility,
Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" which
could not be resolved in the currently
targeted framework.
".NETFramework,Version=v3.5". To
resolve this problem, either remove
the reference "Third.Party.Assembly,
Version=50.11.2.0, Culture=neutral,
PublicKeyToken=0561a7c6dbd6f0ea,
processorArchitecture=MSIL" or
retarget your application to a
framework version which contains
"Microsoft.VisualBasic.Compatibility,
Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a".
[d:\Builds\3\mySolution.sln]
Everything compiles and runs great on my machine, but the build server seem to struggle.
I think the Third.Party.Assembly is written in VB.net.
Since the assembly is third party I can't remove the reference to "Microsoft.VisualBasic.Compatibility" and since I don't get any warnings on my computer could it really be that I'm running v3.5?
Any suggestions?
/Jimmy
If you put your project on the build server manually will it run? Based on the error message, I would make sure you have the latest .net framework installed on the build server machine and give it another try. If that does not work try installing VS2010 on the build server just to get the builds running until you find out just exactly what assemblies you are missing.
So, I was having this issue also on a VS2005 project that we upconverted... The issue is that MS has never had a 64-bit version of the VisualStudio.Compatability DLL. Our issue was that we were targeting 'Any' CPU and building on a new W2008R2 server so it was using the 64-bit version of the .NET 4.0 Multi-targeting pack.
In the build properties under the 'Process' tab under the '3. Advanced' there is a 'MSBuild Platform'. Change that value to "X86" and it might work... assuming of course you aren't depending on any 64-bit libs...