I built a class library as a NuGet package to be used in another C# project. When I built the class library, I followed a tutorial that suggested targeting .NET Standard 2.0.
I installed the package into the other project and it builds fine. However, I've noticed that the output folder contains several other 'System.' dlls (ie. System.AppContext.dll).
In the past, when I've built a class library for C++, I did not get the dependent dlls copied to the output folder. I had assumed that building a C# class library would act the same way. For C++, those dependent dlls are resolved at runtime by the C++ redistributable dlls. I thought the same would be true in that C# would resolve them through the installed framework.
So, I'm a bit confused as to why the extra dlls are present in the output folder. Is it because I targeted .NET Standard 2.0? Do I need to ship the extra dlls with my application?
Related
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?
I am building a simple library with TeamCity and Octopack because we want this library to be shared with multiple other projects.
I am building it successfully and the .nupkg file has the following internal format.
./{DLLName}.dll
./{DLLName}.pdb
These libraries are made to compile to .NET Framework 4.0 due to needing to be compatible with legacy applications. The projects definitely are set to compile as .NET Framework 4.0.
I believe the problem is that packages are supposed to be build with a format like below.
lib/{DLLName}.dll
lib/{DLLName}.pdb
How do i make octopack put the contents in a lib folder like that?
OctoPack is not designed for that purpose (packaging libraries). It is for packaging applications and other distributables for use with automated deployment tools (primarily Octopus Deploy). Octopus chose the NuGet package format due to the the ease of distribution through existing NuGet feeds and protocols, a convenience. It does however not follow the official conventions when packing, to allow a library to be used by a project
From the documentation:
OctoPack should only be installed on projects that you are going to deploy - that means the console application projects, Windows Service projects, and ASP.NET web applications. Unit tests, class libraries, and other supporting projects wouldn't be selected.
I suggest you use another method, such as this one
I've added a new Class Library (Package) project to my solution. It's my first experience with a .NET Core (or whatever I'm using, still confused)
My class library contains two references: .NET Framework 4.5.1 and .NET Platform 5.4
I'm trying to import some code from a sample project that uses IPrincipal. For some reason it's saying that it doesn't exist on namespace "System.Security" altohugh I can get it trough intellisense.
What's wrong with my project settings?
The new feature of .NET Core and Class Library (Package) is that it targets multiple platform and will compile into multiple assemblies which get automatically packaged into a nuget package.
When your class library targets multiple targets, it will compile to all of them. So if a certain library is only available on full .NET framework but not on .NET Core or other target framework, then you may receive intellisense if your editor is set to .NET 4.5. More information can be found in my other recent answer.
You can switch back and forth with the pull down menu on top left of the coding window, show in the screenshot below.
If you do not want to target a certain framework, you have to remove it's moniker from the project.json file or use preprocessor directives to write platform specific code or libraries/replacements.
.NET Core is heavily modularized and most of only the core modules are referenced in the default project and if you need additional one you need to reference them within the dotnet5.x section.
Basically you have multiple places with "dependencies" in your project.json, a global one where you can add dependencies which are available on all targeted frameworks and one within each "frameworks" section for each of the targets only.
Though the other answer covers some basic concepts, it would require some attention on which classes are available and which are not.
Microsoft temporarily host a web site at http://packagesearch.azurewebsites.net to assist.
If you can find a suitable package for RC1 from there, then you can add it to your project.json file. If not, you will have to conditional compile it to a desktop profile or use other alternatives.
Will (or does) the DNX project support frameworks other than ASP.net (Such as WPF or windows forms)? I'd love to create some Wpf class libraries using the newer json project style (and native NuGet package support), but everything seems to be geared towards Asp.net.
Dnx is only for ASP.NET 5 projects (web, console or library).
It doesn't support WPF.
The project.json/xproj based project model (I would not call it DNX projects) can indeed be used to build nuget class libraries for scenarios beyond ASP.Net and DNX.
If you specify in your project.json a SDK like net451 you can additionally add frameworkassemblies like "PresentationCore" or "PresentationFramework" and then start coding in class files against WPF. So you can create a class library with it (i just tested it). It builds and packages itself to NuGet. That NuGet you can use then in your normal WPF project.
It is important to understand the concept of a SDK when talking about the new .Net Framework things: DNX is a SDK similar to UWP or the .Net Framework (WPF/WinForm). The SDK then specifies which CLR and BCL are used in combination with the features of the SDK. Consequently, this project format does not target the DNX SDK (from the architecture) but any SDK. In the end a class library is IL which has references to DLLs. Support for direct references with normal .csproj is planned (IMHO).
But there are restrictions: The project format is new, not yet well supported and integrated, there is no and maybe never will be a WPF designer etc.
I have built a C# class library on the .Net framework 4.5.1. I am using the Json.Net library. However I would to have the same class library be compiled for at least .Net 2.0, 3.5 and 4 and packaged as nuget package. The reason why I am saying that is the only thing that change is the Json.Net because it is built to run on different .Net platform. I have read many suggestions online. However I would like to have a step by step guidance to put this up and running.
So far what I have done is to create various projects and change the target framework and build them to get the dll. Now I would like to have it in one if it is possible.