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
Related
.Net Core 3.1. I used System.Runtime.Caching library, it depends on System.Configuration.ConfigurationManager.
But there is a amazing thing happened, I test it in MS unit test project[.NET Core 3.1], it runs well, then in Azure Function project[.NET Core 3.1], it will throw 'Could not load file or assembly 'System.Configuration.ConfigurationManager, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.' error, and in project .deps.json, also have dependency configurations
Below is Stack Trace:
System.Configuration.ConfigurationManager 6.0 won't support .net SDK 3.1, so update the "System.Configuration.ConfigurationManager" version to 4.7.0 and any other lower version. and try it.
According to your description, it seems it missed the nugetpackage System.Configuration.ConfigurationManager inside your application.
I suggest you could install the package System.Configuration.ConfigurationManager inside the local and re-publish again.
Install-Package System.Configuration.ConfigurationManager
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.
I am trying to upgrade a project from VS2005. It is a VB.NET project B that depends on a C# project that references a C++ dll, A.dll. I am getting an error saying 'Unable to find assembly A_class, Version 2.0.0.0, Culture=neutral, PublicKeyToken=null'. The targeted platform of the C++ project is 4.0 and since that project depends on others, I can't downgrade it. But I did set the platform for the VB.NET project to 4.0. What else does the Version 2.0.0.0 refer to ? I have tried to create a brand-new project and added the vb forms into it after I have built it successfully. The C++ dll is in the output directory, if the VB project doesn't find it there, it doesn't get to this point. During build. I either get no error (but forms don't load) or I get 2 errors (one for each form):
error MSB3103: Invalid Resx file. Could not load file or assembly 'A-class, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format. Line 136, position 5.
Please help me, give me a suggestion, I don't know where to look. thank you very much.
"An attempt was made to load a program with an incorrect format"
99% of the time this means you are trying to load a 32-bit assembly using 64-bit tools, or vice versa. The version number in the error message just means the version number of the assembly that it's trying to load; it has nothing to do with .NET version being targeted. In this case it appears that the resource compiler is what has issues.
Try configuring your solution to explicitly build x86 instead of Any CPU and see if that resolves your problem.
I have a system that implements several web services in C# 4.0. The solution is being compiled under TFS2010's build mechanism. After the build, some low level tests are run.
These run correctly in developer studio (on Windows 7), but for some reason fail under MSTest on the build machine (Windows Server 2008 R2). Some logging shows that it's caused by a System.IO.FileNotFoundException exception on an assembly at the bottom layer (see exception stack below).
Do you think it's a versioning problem? Is Windows Server 2008 R2 doing something completely different that the Castle asembly doesn't grok?
Type: System.Reflection.TargetInvocationException
Error Message: Exception has been thrown by the target of an invocation.
Source: mscorlib
Type: Castle.MicroKernel.SubSystems.Conversion.ConverterException
Error Message: Could not convert from 'MockRepository' to System.Type.
Source: Castle.Windsor
Type: System.IO.FileNotFoundException
Error Message: Could not load file or assembly 'VsWebSite.Interop, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
Source: mscorlib
EDIT: I never did find out what the problem was. I had a large amount of refactoring to do and, after that was over, the issue disappeared.
Something is referencing VsWebSite.Interop.dll (definitely not any Castle assembly) which is a Visual Studio assembly, and you probably don't have Visual Studio installed on your build server. Remove that reference.
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...