If I create a .NET Core Class Library in Visual Studio 2017, I get the Package tab on project properties. If I create an "old fashioned" Class Library, I do not get the Package tab, nor the "Pack" target in MSBuild.
NuGet is integrated into VS2017 and MSBuild to some degree, but it seems to be only for .NET Core projects.
Is there a way to use any of the NuGet integration for non-.NET Core projects or do I just need to install the NuGet CLI and use a .nuspec file?
This support for integrated packaging needs "SDK-style" csproj files which are used for .NET Core and .NET Standard projects. Since a few features (like some designers) aren't yet available for these projects, there are no templates for "SDK-style" csproj-based projects for .NET Standard.
However, you can create a .NET Standard project and change the csproj file from
<TargetFramework>netstandard1.6</TargetFramework>
to a net* moniker like
<TargetFramework>net461</TargetFramework>
This gives you all the tooling for creating NuGet packages and managing versions and metadata.
Related
I have a project ("Project1") that has a reference to an Assembly that I created in another project ("Project2").
I just added a function to a class in that assembly, but that function required me to add the NuGet package System.Drawing.Common. Which isn't an issue.
Here's the issue:
When I build Project1, it does not bring System.Drawing.Common.DLL to the bin folder. So, at runtime, when I execute this new function, I get an error stating that it can't find this DLL.
Is there a way that I can have Project1 bring along all of the Assembly's dependencies? Or do I have to instead add all the same NuGet packages that Project2/Assembly uses to Project1?
I'd prefer the former. I'm using ASP.NET Core 2.2 and Visual Studio 2017.
Thank you.
The build command with .NET Core 2.2 does not bring in the dependencies by default this is for testing only. If you are wanting all the dependency .dll to be included for deployment you should use the publish command to get all the .dll from your NuGet packages. There are other switches to include the framework as well so you don't need to install the framework, on the host.
As a friendly reminder, Dot Net Core 2.2 support will end on December 23, 2019
Based on documentation https://learn.microsoft.com/en-us/nuget/schema/msbuild-targets, it looks like msbuild now support 2 specific targets for NuGet: Pack and Restore.
I have been able to use Restore properly, but not Pack.
error MSB4057: The target "Pack" does not exist in the project.
Is it supported for traditional .Net project or is it a .Net Core thing only?
I haven't been able to find any documentation stating it clearly.
Regarding required dependencies, I am using
PM> nuget help
NuGet Version: 4.1.0.2450
usage: NuGet <command> [args] [options]
Type 'NuGet help <command>' for help on a specific command.
And
C:\Git>msbuild /version
Microsoft (R) Build Engine version 15.1.1012.6693
Copyright (C) Microsoft Corporation. All rights reserved.
15.1.1012.6693
With
Microsoft Visual Studio Professional 2017
Version 15.2 (26430.12) Release
VisualStudio.15.Release/15.2.0+26430.12
Microsoft .NET Framework
Version 4.6.01586
It is supported out of the box for "SDK-based" projects. There is no project template in VS for .NET Framework libraries using this ""new-style csproj"", but you can create a .NET Standard library project and manually change the TargetFramework property in the csproj file from netstandard1.6 to net461. Note that the project system that is used for these types of project doesn't support many features available in classic .net projects yet (like designers for WinForms, Xaml, edmx).
The resulting project file would look like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net461</TargetFramework>
</PropertyGroup>
</Project>
Looks like I did not Google enough... this blog post clearly speaks about .Net Core only: http://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html
Some of the features discussed earlier are not yet fully supported for
packages.config based projects such as defining nuspec metadata in
project files, building packages directly from a project, [...]. We are hard at work to bring full PackageReference support to
these project types. Our goal is to eventually make PackageReference
the default and move away from all other formats.
I have a .NET Standard library (1.4) VS 2017 project that contains custom MS Build task (MyTask) that need to be distributed via Nuget package (Let's say MyCustomTask.dll and it contains MyTask and Portable.targets that will be imported by target project)
This Nuget package with custom build task is then used by target .NET Standard (1.4) project cspro file to import the Portable.targets that invoke the Custom Build task.
However, at this point I keep on getting the build error
Could not load file or assembly 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
I tried .NET Standard (1.4, 1.5 and 1.6) but same error.
The problem is that the consuming application, MSBuild.exe in this case, would need to include all the forwarding assemblies necessary to run netstandard tasks (e.g. depend on the NETStandard.Library).
The best solution in this case is multi-targeting the task library to a .net framework and a .net standard target framework:
<TargetFrameworks>netstandard1.6;net46</TargetFrameworks>
The idea is to have 2 dlls that will contain the task. In the project files contained in the NuGet package instead of using a dll path directly in <UsingTask>, the idea is to using a different dll file based on the $(MSBuildRuntimeType) property, which will be Core on the .NET Core version of MSBuild:
<PropertyGroup>
<_CustomTaskAssemblyTFM Condition="'$(MSBuildRuntimeType)' == 'Core'">netstandard1.6</_CustomTaskAssemblyTFM>
<_CustomTaskAssemblyTFM Condition="'$(MSBuildRuntimeType)' != 'Core'">net46</_CustomTaskAssemblyTFM>
<_CustomTaskAssembly>$(MSBuildThisFileDirectory)..\tools\$(_CustomTaskAssemblyTFM)\CustomTaskAssemblyName.dll</_CustomTaskAssembly>
</PropertyGroup>
<UsingTask TaskName="SomeCustomTask" AssemblyFile="$(_CustomTaskAssembly)" />
You can see examples of this in the asp.net core build tools and the .NET Core SDK.
I am working with .Net Core 1.0 (running under the .Net Framework 4.6.1, non-portable).
I need to include some DLLs that are from a locally-built GitHub project. When I build those projects, and then attempt to "Add Reference" to the resulting DLLs, I get a message saying I can't add them to a Core project directly.
After more research, I found a lot of information regarding "private" NuGet packages. However, those seem overly complex / overly engineered.
Is there any way I can do the following:
Without having to go through the headache of creating a private NuGet repository, can I just "add reference" to the built assemblies that are sitting in the bin folder of the NuGet projects I pulled?
I really don't want to have to build a local-only NuGet package. Mostly because I've already wasted too much time on this issue, and because I read this entire concept is about to be scrapped and turned into something else (sounds familiar by now)... such as the Roslyn-based build system on GitHub.
My current state:
Visual Studio Professional 2015
.Net Core 1.0.1
.Net Core 1.0.1 Tooling Preview 2
No, as for now you have to create a nuget package before and restore it via Nuget. You can use a simple folder as NuGet source, so if you put your compiled NuGet package in C:\packages, you can add this as a source to NuGet (while in the NuGet UI, click the settings Icon and add the folder as new source).
This may change with the next release of ASP.NET Core (1.1), as the .NET/ASP.NET Core team is working to move from *.xproj to *.csproj files.
One of the reasons why you need to use nuget is because it can contain multiple targets and project.json allows you to target multiple platforms (i.e. net452 and netcoreapp1.0).
I wanted to create a new ASP.NET Core app targeting the new .NET Core 1.0.
First, in Visual Studio 2015 Update 3, I don't see .NET Core listed
And this is what I'm seeing in project.json file. Looks like I'm targeing dotnet5.6
Is it safe to assume this is all correct?
And if this is correct, could it possibly be more confusing?
The pulldown has no meaning for .NET Core projects as it doesn't use it. Only what's in project.json matters for .NET Core / .xproj projects.
netcoreapp1.0 target framework moniker (short TFM) is .NET Core project for executables (ASP.NET Web Application or .NET Core Console Application). netstandard1.x (see this matrix for api surface of netstandard TFM) is for class libraries.
The import section just tells nuget to also restore packages which target dotnet5.6 (old TFM for .NET Core Library, which is now replaced with netstandard1.x) and portable-net45-win8, which are also compatible with .NET Core. These allow you to install packages which are compatible but are not yet repackaged for netstandard1.x.