I thought this problem was fixed. I'm using Visual Studio 2013 and it is Entity Framework 6.1. I get the error message: PublicKeyToken=xxxxxx is not marked as serializable.
I thought this was fixed. Is it broken again and if so, is there a workaround?
Thanks.
Here is the complete error message when trying to install into a win32 C++ console application. (Built with default settings, no other adds to new build.)
Error: Type
'Microsoft.VisualStudio.Project.VisualC.VCProjectEngine.VCProjectShim' in Assembly
'Microsoft.VisualStudio.Project.VisualC.VCProjectEngine, Version=12.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.
Here is the complete error message when trying to install into a C++ CLR:
(Actually, it's the exact same error message.)
Here is the complete error message when trying to install into a General Empty C++ Project:
(Again, same error message.)
Okay, I can finally figure out what you are doing. You are trying to run Nuget to download and install the Entity Framework into a C++ project. Yes, that's going to be a fail-whale. Nuget acquired the ability to install C++ libraries at version 2.5, but that only works for native libraries. Pure C++, not managed code like EF. Being a relatively new feature, it doesn't do anything to stop you from getting it wrong, it doesn't filter the available packages to the kind that can work in a C++ project.
The step that fails is the final one, download and copying files work okay but then Nuget runs a Powerscript script to modify the project properties. Which, for EF, was written to work in a C# or VB.NET project. The VS extension model for C++ projects (implemented by the VCProjectEngine class as reported in the error message) is too different to permit that script to complete successfully.
Do keep in mind that the odds of using EF in a native C++ projects are zero. You'll only have a smallish shot at it in a C++/CLI project. Starting with a project template in the CLR node is a required first step.
The next one is to fool the Nuget installer, add a dummy C# project to your solution and run Nuget to get EF installed into that project. You'll see it adding an app.config file to the project, you need to do the same in your C++/CLI project. And it adds two EF assemblies that you also need to add to your C++/CLI project:
Right-click the project in the Solution Explorer window, Properties
Select Common Properties + References
Click the Add New Reference button
Click the Browse button
Navigate to the dummy C# project's packages\EntityFramework.6.1.0\lib\net45 directory
Select EntityFramework.dll you see there
Repeat to add EntityFramework.SqlServer.dll there.
Be sure to write C++/CLI code to use it. Beware that you'll have a Eskimo's chance to find any. The much saner approach is to create a C# library that uses EF and use that library in a C++/CLI project.
Related
I have a Xamarin Forms Project, and I do use ShinyLib.net Package https://github.com/shinyorg/shiny.
I do have some bugs with Shiny, which I would like to track down and Fix.
How can I make my project use the Source Code from Git instead of the Nuget Packages so I can Debug and Make changes and try to fix some bugs? Shiny already is using .Net MUAI, but it is still compatible with Xamarin.
I tried to Download the Shiny Source Code, and in my Project, I use Add Existing Project, but it shows me that is Incompatible, and it fails when compiling :
Shiny.BluetoothLE is not compatible with netstandard2.1.
Can someone please explain the correct way for me to compile using source code instead of Nuget Package?
I have a project that targets two different operating systems/frameworks:
net461 on Windows and
netcoreapp2.0 on OSX
I'm trying to figure out how to correctly package this for NuGet. According to this post I should be able to package them like this:
/runtimes/win/lib/net461/myassembly.dll
/runtimes/osx/lib/netcoreapp2.0/myassembly.dll
By when I add the NuGet package to another project, the packaged assemblies aren't added as references to the target project.
Then I read somewhere that you also need to add reference libraries to the /ref folder so I tried this:
/runtimes/win/lib/net461/myassembly.dll
/runtimes/osx/lib/netcoreapp2.0/myassembly.dll
/ref/net461/myassembly.dll
/ref/netcoreapp2.0/myassembly.dll
In this case the assemblies get added as a reference to the target project and I can build it, but the required assemblies aren't copied to the output folder.
The documentation on all this is extremely vague and I'm fairly lost.
What am I missing?
Associated NuGet Issue: https://github.com/NuGet/Home/issues/7316
Update: I've put together a sample project that demonstrates what I'm trying to achieve. In particular see the bottom of the readme, titled "NuGet Packaging".
This is what I've finally figured out/guessed (because as best I can tell there's no official documentation for some of this)
Files added to the /runtimes folder aren't automatically added as references to the target project.
The /ref and /runtime folder should be used in conjunction with each other and only for the .NET Core target. As best I can .NET Framework targets apparently don't support these folders.
The /ref folder is for compile time references and anything added here will be added as a reference to the target project.
Assemblies in the /ref folder don't need to have an implementation - every public API could just throw a not implemented exception. In practice however you typically just take a copy of one of the implementation assemblies and declare it as the compile time API.
I've read (but haven't tested myself) that assemblies in the /ref folder must be "Any CPU" builds. You can use CorFlags utility to patch an implementation assembly for this if necessary.
The /runtimes folder is used to provide an implementation assemblies for any references included in the /ref folder. These assemblies are used at runtime and during deployment.
The /runtimes folder can include additional assemblies that are only required at runtime and don't need to be seen by the client project. These additional assemblies won't be included as references in the target project but will be available for run/deployment.
As mentioned by others, the files in the /runtimes folder aren't copied to the output folder of the build. Instead config files are placed there that tell the runtime how to locate the /runtimes files from the NuGet cache.
For .NET Framework targets (ie: net461) just use the /lib folder as there's no other runtimes for .NET aside from Windows anyway.
Putting this all together, my original example, should have looked like this:
/lib/net461/myassembly.dll (net461/Windows Compile and Runtime)
/runtimes/osx/lib/netcoreapp2.0/myassembly.dll (netcore/OSX Runtime)
/runtimes/win/lib/netcoreapp2.0/myassembly.dll (netcore/Win Runtime)
/ref/netcoreapp2.0/myassembly.dll (netcore/* Compile Time)
I spent a fair amount of time trying your project on OSX in both Visual Studio for Mac and VS Code. I'll try to stick with factual observations without getting into "why don't you do X instead".
The runtimes/{rid}/lib/{tfm}/*.dll paths look ok
target="lib/{tfm}/..." assemblies are automatically referenced, runtimes/... are not
Using target framework of netstandard seems like it would make your package work in both netcoreapp and netstandard projects (e.g. use target="lib/netstandard1.6/..."). Compare with this
runtimes/ seems to be intended for platform-dependent assemblies you'll load at runtime. For example, 32/64-bit native assemblies in runtimes/win-x64/native/ and runtimes/win-x86/native/) loaded with AssemblyLoadContext (another post by McMaster)
Using separate slns for Windows and OSX, or separate platform-specific projects that reference platform-agnostic projects (like Xamarin) would obviate some of the configuration wrangling
I found no documentation on target="ref/...", but you can add Explicit Assembly <references> (inside the nuspec <metadata> block)
Packaged assemblies won't appear in the output directory, but when prepared for distribution with dotnet publish they'll be included:
.NET Core and .NETSTANDARD don't copy dependencies to output directory, they are mapped using deps.json which points to relative paths from local NuGet cache.
This has been a very useful thread to get more information and hints on how to create a NuGet package that references native DLLs, and is consumed in both .NET Framework as well as .NET Core / modern .NET libraries / applications.
My experience so far has been that if this library (let's call it library A) only targets .NET Standard, consuming this library in a .NET Core / 5.0 or 6.0 application does lead to the native assemblies being pulled in correctly from the runtimes folder. In a .NET Framework 4.7 application however, this does not appear to be the case. Unless the runtime is explicitly specified when compiling, e.g.:
dotnet build ... --runtime win-x86
When using library A in a .NET Core or .NET 5.0/6.0 application however, this runtime identifier is not required - all runtimes are made available and the right one is selected at runtime.
If you want library A to be consumed in applications that also target .NET Framework, and you don't want the user to have to specify the runtime explicitly, then it seems to be necessary to:
Target both .NET Standard and .NET Framework
Ensure that the native assemblies end up in the following folder structure in the NuGet package:
"lib/{tfm}/..."
While the .NET documentation referenced by tm1 earlier here talks about how to get this to work using nuspec files, it is less clear how to do so in the SDK .csproj format. I managed to do this in the NLoptNet project, see the relevant .csproj file here. Final relevant point (in addition to the two bullets above):
Use "<None Include" rather than "<None Update" to add the native assemblies
So far - this works, but there is one quirk - as you can see here it generates warning MSB3246 when consuming library A in a .NET Framework application. See also this Stack Overflow post. This leads me to believe that maybe the above is not the right approach, and therefore to some questions:
Is this the intended way to consume library A in .NET Core, modern .NET and .NET Framework applications?
Should one always specify the runtime identifier when using dotnet build / dotnet test?
Can you try to target .NET Standard 2.0 instead of net461 and netcoreapp2.0? Libraries built against netstandard2.0 should work with .NET Core 2.0 and .NET Framework 4.6.1: https://learn.microsoft.com/en-us/dotnet/standard/net-standard
Are you using the new csproj format? If so it has built in support for multiple target frameworks.
For example running dotnet pack against a .csproj file with this content:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net461;netcoreapp2.1;netstandard2.0</TargetFrameworks>
</PropertyGroup>
</Project>
will result in a .nupkg that works for .NET Framework 4.6.1, .NET Core 2.1 and .NET Standard 2.0.
Various trick can then be used to include specific parts for each framework depending on what's available.
I'm trying to solve the same problem.
The solution proposed by you works fine, but there is one question ...
The case of Win and net46 is clear. And now I need to add a reference to the assembly in the project for a netcoreapp for the Win and for Linux. The problem is that this is a DIFFERENT assembly with the SAME name. Those my package looks like this:
/lib/net461/myassembly1.dll (net461/Windows Compile and Runtime)
/runtimes/ubuntu/lib/netcoreapp2.0/myassembly2.dll (netcore/Ubuntu Runtime)
/runtimes/win/lib/netcoreapp2.0/myassembly1.dll (netcore/Win Runtime)
/ref/netcoreapp2.0/???
Update: Actually, the myassembly1.dll and myassembly2.dll are both called myassembly.dll. But to show that one is assembled for Windows, and the second one for Linux, I will leave here such a name.
The most interesting thing is that I tried to put any assembly in the folder ref, and it works on both Windows and Linux.
This version works on both systems
/lib/net461/myassembly1.dll
/runtimes/ubuntu/lib/netcoreapp2.0/myassembly2.dll
/runtimes/win/lib/netcoreapp2.0/myassembly1.dll
/ref/netcoreapp2.0/myassembly1.dll
And this too
/lib/net461/myassembly1.dll
/runtimes/ubuntu/lib/netcoreapp2.0/myassembly2.dll
/runtimes/win/lib/netcoreapp2.0/myassembly1.dll
/ref/netcoreapp2.0/myassembly2.dll
But I think this is not right and I was wrong somewhere.
I have a .NET Standard 2.0 class library project with installed Nuget package System.Data.SqlClient version 4.4.0 and a Windows Form .NET Framework 4.7 project that has a reference to that class library.
Installing the Nuget Package and building the solution is successful. but in runtime every time that the code reaches a method that has any thing from SqlClient assembly inside it (for example an instance from SqlConnection) it gets this error:
Could not load file or assembly 'System.Data.SqlClient,
Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
Considering this question, I assume the problem was also there in the last major version of the Nuget package.
Edit
I downloaded the Nuget package and unzipped it and from \ref\netstandard2.0 folder copied the System.DataSqlClient.dll manually in \bin\Debug folder of my Windows Form Project and now it works. The exact situation also happened with Microsoft.Win32.Registry package. So I was almost convinced that it's my fault and I'm doing something the wrong way, but when I tested it with System.Drawing.Primitive Package it worked perfectly without any need to copy a dll. Now I'm really confused.
I guess you may have figured it out already but hope it would help someone - wasted some time too on this.
So, in order to make everything work you would need to reference System.Data.SqlClient in Windows Form project that is referencing your .NET Standard Library
From that point everything should be working like a charm
As you already mentioned System.Data.SqlClient.dll was not in output directory.
Sounds like .NET Standard Library haven't grabbed with itself dependent library binary. There is nothing like "Copy Local" option in .NET Standard references so I don't see any way to check or set this behavior too
I had same problem.
Solution for me was adding dependecy from nuget for latest System.Data.SqlClient at my .NET Standard Library project.
I had the same problem. The .NETStandard assembly was added as a reference to my WPF project. I needed to make changes in the .csproj of the WPF project.
The solution mentioned in https://github.com/dotnet/sdk/issues/901 fixes it.
Steps:
Edit your core .csproj file in notepad.
Add the below two lines in each that you find in it.
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
Clean and rebuild your solution.
I had a similar problem, bindingRedirect helped in my case:
<bindingRedirect oldVersion="0.0.0.0-4.4.0.0" newVersion="4.4.0.0"/>
I have a Powershell Tools for Visual Studio 2015 project that is a script module. I would like to add a project reference to a .NET 4.5 class library that is also a project in the same solution. From a visual perspective the dependency is listed under the references tree in the powershell project but it has the warning overlay icon on it. When running the pester tests they error out with a type resolution error (Cannot find type [IHE.Cda.TrifoliaParser]: verify that the assembly containing this type is loaded). I cannot find any documentation which indicates whether what I am attempting is even possible. Thus my question is whether it is possible or if the references list is just a artifact of being in visual studio.
Solution Explorer View
The References are an artifact of VisualStudio. It would be possible to generate an Import-Module <PathToThe>.dll line on top of every script in your project, but that's very obtrusive, and not every script will need all the dependencies.
What can I do to fix this build? Entity Framework was added to this project via NuGet.
All projects compile without issues on local system. But the build fails on Visual Studio Online.
By turning on Diagnostic logging, I am able to trace to this warning which makes my builds failed:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "EntityFramework.SqlServer". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
DO NOT right-click the project and chose "Enable NuGet Package Restore". This is the "old way" of doing package restores as per the Nuget Docs.
Package restoration should happen as part of the build process by default. If it's not (which seems to be the case), you've got a different problem, but there's not enough information to say what.
I am able to resolve this error simply by right clicking at the solution in Solution Explorer and select Enable NuGet Package Restore.
That adds a few more files to my solution and modify a few project files. The build server can then restore the packages at build time and is happy in the end.