I have an SDK project in my solution. And i need to add a NuGet package ("customLib.net"), which provides the functionality to find the differences between files.
If you create a simple .Net Framework 4.7.2 console application and add this NuGet to it, then it will automatically download it along with all dependencies, including "customLib.redist.windows.x64". As i understand "customLib.net.dll" is an API for .net, and "customLib.dll" (which comes from "customLib.redist.windows.x64" package) is an engine itself, compiled for win-x64. The package is stored in SolutionFolder/packages. And there is a package.config file with all required references. And everything works as expected.
But if to add the same NuGet package to SDK (Class Library) project, which has the same target: .Net Framework 4.7.2, it should also download the NuGet package along with all dependencies. And it does. But it doesn't store the packages in SolutionFolder/packages folder, and there are no any package.config files. It stores them in global NuGet storage on C drive. And the problem is that when i launch the application it throws an exception in runtime:
"Unable to load DLL 'customLib': The specified module could not be found.".
And this dll doesn't exists in output folder. I solved this issue by downloading the "customLib.redist.windows.x64" NuGet package to the project, despite the fact that "customLib.net" already has a reference to this package. This is a little bit weird for me, and here are the questions:
Why, if a "customLib.net" depends on "customLib.redist.windows.x64", it does not copy dependent dll to the output folder? At the same time, the console application copies both libraries.
Why after downloading "customLib.redist.windows.x64" NuGet the "customLib.dll" file shows in my project root in Visual Studio with full path to "C:\Users\MyUsr\.nuget\packages\customLib.redist.windows.x64\1.0.1\runtimes\win-x64"?
As per the description, I can assume that you have .NET standard console application but you added the .Net core class library into it. That's why you are facing such issues.
Because in the .NET core library project, there is no package.config file and references were added directly to the csproj file. As well as packages downloaded to the user's directory, instead of the packages folder.
So, instead of adding a .Net core library, you need to add the .NET standard class library into your project
To know more about it refer to What is the difference between .NET Core and .NET Standard Class Library project types?
Related
I have been working maven projects since 2 two years.First of all, I import maven projects to eclipse then
thanks to my pom.xml some dependencies is installed and I see these dependencies on my maven dependencies folder on eclipe project explorer.It connected to my .M2 folder.
Right now , I import a .Net framework project (which is written with C#) in my visual studio program.The solution explorer (references section) show many dependencies(they gives error).Then I found these libraries then I created a folder which is called nugetPackages and I connected my nuget packages manager to that folder(tools/options/nuget package manager/package sources).I reopen my project and libraries on references section does not give any error.My question is where does that libraries names come from ? There are any file like that pom.xml.
I hope I can explain my situation.
Are the libraries (DLLs) that you want to reference in your project NuGet packages or just some framework libraries? If they are Nuget packages they should be described in packages.config file http://prntscr.com/1140xn0 for the classic .NET application (.net framework 4.5 for example) In a .Net Core applications the Nuget packages that are required are defined in the file .csproj file http://prntscr.com/11412iq. In both cases, you can download all required NuGet packages by right clicking on the .sln file and selecting Restore Nuget Packages http://prntscr.com/1140zsk This will automatically create the nugget folder and download all required Nuget packages. If you have manually added dlls you need to navigate to them and select them by right-clicking References - Add reference http://prntscr.com/114142x
I have a UWP app and a bunch of NETStandard 2.0 libraries. The libraries contains a lot of logic and communication interfaces that I am using in ASP.NetCore and Desktop WPF applications, so I am not going to change them.
I use NuGet packages in the libraries so I could reference those in NetCore and NetFramework projects as well. I would like to reference these packages in the UWP project - cause this is the whole point of this standardization concept isn't it?
For the UWP project this does not work. I have the latest Nuget package of System.ServiceModel.Primitives which is 4.5.3 (DLL version 4.5.0.3 - don't ask why) and PublicKeyToken is b03f5f7f11d50a3a - this can be referenced in every project except UWP.
Regardless of every attempt:
- I have installed the Nuget package for the project
- I have referenced the version explicitly in the CSPROJ file
- I have removed every other reference to SDK file version
But still, the UWP project looks for the dll in
C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.netcore.universalwindowsplatform\6.2.8\ref\uap10.0.15138\System.ServiceModel.Primitives.dll
That DLL has version of 4.2.1.1 and the PublicKeyToken is cc7b13ffcd2ddd51
Because the two tokens are different - binding redirects does not work - or maybe I am missing something. Does anyone have a workaround for this?
The whole solution is in VS2019 and I have the latest Win10 SDK installed 10.0.18362.1.
Thank you in advance.
EDIT: I forgot to mention, I have a repro on GitHub
You can create a separate .NET Standard project and incapsulate all your logic (and usage of System.ServiceModel.Primitives assembly) into this project. Then you can add it as a reference to the project with UWP executable.
Also you can setup a binding redirect for strongly-named assemblies by specifying codebase according to this article
There are two C# projects together in one solution
Net.Company.Core
Net.Company.Application
The Core project references a few NuGet packages (e.g. LiteDB 4.1.4). The Application project references the Core project directly (i.e. not via NuGet).
Now when I want to run the Application project I'm getting an exception that a reference to any of the NuGet packages, referenced in the Core project, is not found (FileNotFoundException). In order to resolve this error I also reference the NuGet packages in the Application project.
Question: Why does the Application project need to reference these packages as well? My assumption is that the Core project already brings in these references.
When the Application Project Runs - it runs from its own bin/Debug folder. If you check the contents of that folder you will find the Core project dll and other stuff. But not the dll's libraries/nugets that core project needs. So when the Application project code uses the Core Project and the Core project uses one of those Nugets/libs... it fails becuase those libaries arent in the output (current executing folder).
One way to solve this would be to set the Build Output folder of Core project to be same as that of the Application project.
I'm currently trying to integrate the ILDAsm package in my .Net Core project that contains the executable file ildasm.exe which I want to call from my application. The nuget package is explicitly made for .Net Core and all runtimes (linux, windows, osx, etc.).
Obviously no reference is added to my project after installing the package, but I also have no idea what I have to do to use the package (what is/will be the path of ildasm.exe?).
Just to be clear, I want to use the executable file from my code when my application is running and not on build.
There is an open GitHub issue about providing ildasm with the .NET Core SDK.
The Microsoft.NETCore.ILDAsm NuGet package contains a runtime.json file but no binaries.
This runtime.json file refers to several runtime NuGet packages that contain native versions of ildasm for the different platforms. On the Mac if you install runtime.osx-x64.Microsoft.NETCore.ILDAsm into your project you can then run ildasm from the command if the full path is used:
~/.nuget/packages/runtime.osx-x64.microsoft.netcore.ildasm/2.0.3/runtimes/osx-x64/native/ildasm
I have created the library Staty that I want to publish via nuget for other developers to use.
I explicitly created it as Portable Class Library and restricted myself to very basic programming constructs. Now I want to publish it in a way, that others can easily use my library. I've set up my library as PCL with the following targets, which seemed to me as the most permissive platform-combination:
After completing the first version, I wanted to publish it, using Nuget GUI with the following nuget profile. I included the release-build files into the package under the portable-net4-sl4-wp7-win8 folder (I've tried portable-net45-sl5-wp8-win8 too, without any effect)
To verify, that my library is truly portable, I wanted to include it into another PCL-project, but unfortunately I'm only getting the following error: Could not install package 'Staty 1.0.0'. You are trying to install this package into a project that targets '.NETPortable, Version=v4.5, Profile=Profile259', but the package does not contain any assembly references or content files that are compatible with that framework.
When adding it to a regular console-application, everything works fine. It also works fine, when directly including the dll into that very same PCL-project via References -> Add Reference ... -> Browse.
So what is wrong with the way I published the package?
Additionally I tried adding folder dotnet and net45 to the nuget package with the same dlls - without any success.
In the Change Targets dialog, you are specifying .NET Framework 4.5, whereas in your NuGet setup you are targeting net4. Moreover, in the NuGet setup you are also targeting sl4 and wp7. All in all, this means that when the NuGet Manager tries to match the library path in your NuGet package with the profile of your other PCL project, it is bound to fail due to incompatibilities.
Please take a look at this list to determine in which lib sub-folder you should place your Staty.dll PCL. (The list does not explicitly specify ASP.NET Core and Xamarin targets, they are normally implicitly accounted for.) From the list you can see that the target platforms you selected in the Change Targets dialog matches Profile 259, and the NuGet target for this profile should preferably be portable-net45+netcore45+wpa81+wp8.
(If you open the Staty.csproj project file in a text editor, you can confirm that the <targetFrameworkProfile> is indeed Profile259.)
Please change the lib sub-folder name in your NuGet file to portable-net45+netcore45+wpa81+wp8, and you should then be able to reference the Staty NuGet package from your other PCL project as long this other project targets the same or a sub-set of the platforms that the Staty NuGet package is targeting.