In *.csproj of my aspnetcore app I see:
<PackageReference Include="NuGet.CommandLine" Version="4.1.0" />
What it is good for?
If my environment hadn't NuGet CLI I wouldn't be able to restore this package. When I have it I don't need the package, do I?
What it is good for?
TLDR, it is good for bringing NuGet capabilies to Linux and Mac.
According to docs:
The NuGet CLI is the command-line utility for Windows that provides
all NuGet capabilities; it can also be run on Mac OSX and Linux using
Mono, or through the .NET Core CLI (dotnet).
So it is just cross-platform command-line version of NuGet Package Manager in Visual Studio, which is Windows only. So if you using Visual Studio in Window you basically don't need it, you can just use built-in NuGet Package Manager. But if you want use NuGet capabilities in Linux or Mac, or you have just Visual Studio Code in Windows (without Visual Studio 2017) you definitely need this package.
Related
I am building a netstandard2.0, with a series of sub-dependencies, including Azure.Data.Tables. I have found that Azure.Data.Tables on >=12.3.0 is not compatible with 2.2 projects, but version 12.0.0 is (or at least it doesn't crash my .Net Core 2.2 application).
Based on these premises the resolution was simple: put version 12.0.0 in the netstandard library dependencies. There's only one problem, that when I install this library using Visual Studio into my Net Core 2.2 project I get that visual studio decides to install 12.3.0.
I have checked documentation around enforcing certain versions using the allowed wildcards(https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#version-ranges-and-wildcards), such as:
<PackageReference Include="Azure.Data.Tables" Version="[12.0.0]" />
Which produces this package description just before pressing "install".
But it doens't seem to work, Visual Studio simply carries on with the 12.3.0 installation.
It turns out Visual Studio was just using the nuget cache for my locally generated packages. If I either changed the version of the packaged package then the sub-dependencies would change. As well, another way of getting the precise package would be to clear nuget's cache locally: nuget locals all -clear.
I have a lot of legacy code that builds fine on Windows with .Net 4.5
I am trying to build the same on CentOS with dotnet-sdk for automation and licensing issues.
Following the Microsoft link after installing the required packages, this command fails
$ dotnet msbuild sharpTest.sln
/usr/share/dotnet/sdk/5.0.301/Microsoft.Common.CurrentVersion.targets(1216,5): error MSB3644: The reference
assemblies for .NETFramework,Version=v4.0 were not found. To resolve this, install the Developer Pack
(SDK/Targeting Pack) for this framework version or retarget your application. You can download .NET Framework
Developer Packs at https://aka.ms/msbuild/developerpacks
Since I installed dotnet-sdk-5, it seems the solution fails to build. But I could not locate .Net framework 4 for CentOS
How do I resolve this ?
It's referencing .NETFramework. .NETFramework V4.0 is not xplat and therefore not available on anything else than windows. You should try to re-target your solution to net5.0 and make it independent of Windows specific dependencies.
To re-target to net5.0 try the dotnet upgrade-assistant (it's a dotnet tool). Do this on a windows machine first. To address any windows dependencies that won't work outside windows or .NetFramework see the Overview of porting from .NET Framework to .NET
We're migrating a library project to netstandard2.0 from net461. Some libraries doesn't support .NET Standard yet so the hosting application is runnning net461 and are referencing our libraries that use netstandard2.0.
This works perfectly locally with Visual Studio 15.3 where everything runs and builds.
According to the Microsoft documentation .NET Standard with SDK 2.0 implements 4.6.1 which I assume is why it works locally.
When running build in Visual Studio Online (VSTS) fails with multiple errors like:
Package Microsoft.AspNetCore.Mvc 2.0.0 is not compatible with net461 (.NETFramework,Version=v4.6.1). Package Microsoft.AspNetCore.Mvc 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)
I read up on github discussions here and here that talks about similar problems being a tooling issue and added a .NET
Core Tool Installer task to build that installs Core 2.0 but still with no luck.
What do I need to do to get build working in VSTS?
UPDATE:
(Changed title to Visual Studio Build instead of MS Build)
Found this thread https://github.com/dotnet/standard/issues/454 talking about the VSTS needing an update.
I'm running VS Enterprise 15.4.1, VSTS Build is running version 15.3.5 today which is enough according to the issue on github. This is even more confusing.
Found a workaround by using dotnet restore and dotnet build with version 2.* (preview) which works perfectly.
Instead of using MS Build or Visual Studio 2017 build, just replace the build tasks with the following dotnet tasks.
(If you don't have any private feeds you don't even need the dotnet restore command since dotnet build will restore packages for you).
TL;DR; use this instead:
I have installed Visual Studio 2017 Community Edition. Installed it without any specific things selected like C++ development or Windows development etc. After that I have installed Wix through wixtoolset, which downloaded and installed wix tool set components. After that I have installed the Wix ToolSet extension for Visual Studio 2017. Restarted the Visual Studio and trying to create a new project through File -> New -> Project - WiX Toolset -> Setup Project.
It gives the error and does not let me create the project. I am totally new to WiX and have just a little knowledge about Visual Studio.
Initially, I did not select any of the Installation workloads for VS17 and installed it just to make the installation faster.
Through the comments from Azaz, I came to know that NuGet Package Manager is required to install the packages on demand. But since I could not see the NuGet option at all, I tried to install it with Extensions and updates but it did not work. I did a bit of research and found that at least one .Net development workload is required at a time of VS17 installation which will make the NuGet install automatically in VS17.
So I uninstalled the VS17, WiX at all and removed them from the system. Then Installed VS17 with certain workload packages as shown in the below screenshot.
After that I installed WiX and an extension for the same in VS17. i.e. Votive2017.vsix.
I restart the VS17 and now I am able to create project for WiX.
Looks like there is something I missed somewhere in installing which did not let me install required DLLs and GUID feature, which were important for creating project templates.
Sharing the steps I followed in order to fix the same issue that I found with Visual Studio 2019, as I also installed it without any workload. I was also looking at a reduced installation.
The steps I did in order to fix the template error, install the following individual components:
.NET 5.0 Runtime
.Net Core 3.1 Runtime
.NET SDK
C# and Visual Baisc Roslyn compilers
ClickOnce Publishing
Microsoft Visual Studio Installer Projects
Hope it helps someone else. I have to point out that the comments before helped me understand the issue. But, for example, I couldn't even open the NuGet command line.
Upgraded our ASP.Net Core project (using full .Net Framework) from .json project to .csproj format, using VisualStudio 2017, and the project builds and runs just fine locally.
From what I understand NuGet 4 is bundled with VisualStudio 2017.
Trying to build this using VisualStudioTeamServices fails on the "Nuget installer" task, as we can only select version 3.5 of NuGet for this task. (And yes, Visual Studio 2017 is installed on the build server, and the agent has been updated to have the capabilities updated)
There is an argument to enter a custom path for nuget in this task, could this be used? Or do we have to wait for an updated version of the Nuget installer build task?
If anybody else has the same problem, I figured out that we no longer need the "Nuget installer" step. Simply add "/t:restore" as an argument to MsBuild.