Install a Nuget package in Visual Studio Code for Unity - c#

I want to save my level files to .json files in the Unity assets folder. Due to the limited features of JsonUtility I want to use Json.NET. I use Linux so I can't access Visual Studio and use Visual Studio Code instead. I wanted to add the package to my Unity project and took the guide from here
Install a Nuget package in Visual Studio Code
First I used this command in the terminal
dotnet add package Newtonsoft.Json
but I got this error
error: Error while adding package 'Newtonsoft.Json' to project
'/.../myUnityProject/Assembly-CSharp.csproj'. The project does not
support adding package references through the add package command.
After that I installed the Nuget extension and installed Newtonsoft.Json#12.0.2 to my project. I was prompted to run dotnet restore to be able to use the package.
After doing so I got this error
MSBUILD : error MSB1011: Specify which project or solution file to use
because this folder contains more than one project or solution file.
So what is the correct way to install third party tools using Visual Studio Code with Unity?

Unfortunately, due to Unity3D's heavy-handed manipulation of SLN files, it is not possible to use NuGet packages within a Unity project.
In the case of Newtonsoft.Json, it is available on the Asset Store for free, you can install from there.
Other packages can be used manually by downloading the .nupkg file from the NuGet website, extracting the DLLs for .NET 4.x, and placing them in your project's Assets folder.
If the library contains native code, you might not be able to use it on every platform, however. But if you get per-platform DLLs, you can set them up in the Unity editor to only be used for the correct platforms.

Related

docfx metadata step fails with error "Could not load SDK Resolver"

Whenever I try to build any documentation using docfx, I get the following error in the metadata build step that uses msbuild to analyze the xml comments in the code of the csprojs:
Warning:MetadataCommand.ExtractMetadataWorkspace failed with: [Failure] Msbuild failed when processing the file 'C:\temp\docfxtest\docfx_project\src\src.csproj' with message: Could not load SDK Resolver. A manifest file exists, but the path to the SDK Resolver DLL file could not be found. Manifest file path 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\SdkResolvers\Microsoft.Build.NuGetSdkResolver\Microsoft.Build.NuGetSdkResolver.xml'. SDK resolver path: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet\Microsoft.Build.NuGetSdkResolver.dll C:\temp\docfxtest\docfx_project\src\src.csproj
It seems that msbuild cannot be correctly resolved by docfx. Any idea how I could fix this?
Im using docfx version 2.56.5.0 on Windows and I also have VS Enterprise 2019 (16.8.2) and VS Build Tools 2017 (15.9.29) installed:
UPDATE:
I have now uninstalled the VS 2017 build tools completely and repaired the VS 2019 installation using the installer. I now get a different error when I run docfx. It seems that it can't find msbuild at all anymore.
Warning:MetadataCommand.ExtractMetadataWorkspace failed with: [Failure] Msbuild failed when processing the file 'C:\temp\docfxtest\docfx_project\src\src.csproj' with message: The SDK 'Microsoft.NET.Sdk' specified could not be found. C:\temp\docfxtest\docfx_project\src\src.csproj
Running msbuild -t:restore,build also shows that it can't find msbuild
'msbuild' is not recognized as an internal or external command
The targets are isntalled:
And so is the .NET Core workload:
Your Build Tool for VS2017 might have some problems due to some issues. The most issue is this:
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet\Microsoft.Build.NuGetSdkResolver.dll
Either you lost the dll or the dll is damaged.
Update
1) First, you should check whether you have installed NuGet targets and build tasks workload and net core build tools workload. If not, please install it.
2) Second, please delete bin and obj folder of your project and then try again.
You should use msbuild -t:restore,build to build your project.
3) Third, try to Repair from vs_installer for your build tool. It will repair the related dll. And then delete bin and obj folder, use build tool to test your project again.
Important:
VS2017 does not support net core 3.1. You should note that. It supports <=net core 2.1.
So if you still want to use Build Tool of VS2017 for your net core project, you should try the the above three steps and then target your project to net core 2.1.
Besides, if you start msbuild by CMD, I think you should check your environment variable PATH and check whether you have configured the msbuild.exe from Build Tool of VS2017 on it. Instead, you could add C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe. This way is for VS2019.
=================================================
Update 1
The problem is that you have already installed a docfx tool by choco command line.
At the beginning, I always thought that you used docfx.console nuget package on your project and just invoke docfx.exe from C:\Users\xxx\.nuget\packages\docfx.console\2.56.5\tools\docfx.exe under command line.
Regardless of the installation of docfx.console package on your project, if you installed docfx tool by choco command and then just invoke docfx.exe on command line, it used the local docfx.exe under C:\ProgramData\chocolatey\lib\docfx\tools\docfx.exe rather than the nuget package.
So the issue is that your local docfx.exe has some errors due to some issues. You should reinstall the docfx.exe by choco command choco uninstall docfx; choco install docfx.
Actually, directly use docfx.console nuget package on your project might be easier. From this link.
It already contains the generation step of the documentation by docfx.exe(from C:\Users\xxx\.nuget\packages\docfx.console\2.56.5\tools\docfx.exe) and will execute it automatically rather than run docfx.exe again manually.
I have completely uninstalled docfx using chocolatey (choco uninstall docfx) removed every folder named docfxfrom c:\ProgramData\chocolatey\.chocolatey\ and then reinstalled it (choco install docfx). After that, everything worked fine again. The file c:\ProgramData\chocolatey\lib\docfx\tools\docfx.exe.config contains a lot of msbuild related configuration. Maybe something was messed up there.

Nuget Microsoft.SqlServer.Types does not install dlls

I am pulling this project from a git repository that depends on Microsoft.SqlServer.Types which should install msvce120.dll and SqlServerSpatial140.dll. But for some reason it does not install them. They appear in the solution explorer as seen on the image. But the files are not there in windows explorer.
The project was cloned from a git repository. As soon as I tried to build the project, VS started downloading the necessary nuget packages, but this files fail to download. The original repository has these files marked as git ignored.
Where am I going wrong here? I could simply copy and paste the dlls from the original repository but I want to understand why they are not being downloaded or installed.
If you installed this package into a project using the <PackageReference> style of packages (typically found in .Net Standard / .Net Core applications), then the files are not added because there is a lack of support for the install / uninstall scripts used for this function.
Specifically, when installing / restoring this package, there is an install.ps1 script that is supposed to be ran which creates the folders and places the dll's you're referencing into these folders. Again, there is no support for this functionality in the <PackageReference> style of packaging.
This is juxtapose to the packaging style that uses Packages.config which DOES have support for install / uninstall scripts.
You can read more about this here: https://github.com/NuGet/Home/issues/6330

Updating nuget package with and without prerelease flag in a C# project

We are using git as source control and we follow the git flow workflow.
We are using Visual Studio 2013
We are using Teamcity v8.1
We have 2 C# solutions. Solution A and solution B. Solution B uses a nuget package that solution A creates.
We are using teamcity as a build server. We have 2 build configurations that creates the Project A nuget package. One build configuration creates a prerelease version of the nuget package, the other one creates the stable version of the nuget package.
The build configuration for creating the prerelease nuget listens on the develop branch. The build configuration for the stable version listens on the master/release/hotfix branches
When we work in the develop branch we use the prerelease version of the nuget package.
But when we create a release branch we want to use the stable version of the nuget package.
What we have tried so far is:
In project B csproj file, we have added an element in the BeforeBuild target that executes nuget.exe to update the prerelease version of the nuget package. That works well, since every time we build project B we will get the latest prerelease version of the nuget package.
But when we are in the release/master/hotfix branch we don't want the prerelease version, we want the stable one.
I've created a powershell script that is executed from project B csproj file in the BeforeBuild target
In the powershell script I can find which git branch we are in, but I haven't found a way to update the nuget package to the latest stable version using nuget.exe. If I could use the nuget cmdlets in the powershell script I could run the update-package with the version flag, but that is not supportered when using nuget.exe
Do you do something similar and how have you solved this?
I while back I also tried to automate updating and installing packages with Powershell. As far as I know there is no way to use the Visual Studio cmdlets outside Visual Studio.
You could do everything yourself. Update packages.config, run nuget update, update csproj file.
It is possible your package has an install.ps1 file. This also uses the Visual Studio cmdlets. For example, the install.ps1 can add a config file to the Visual Studio project and set Copy to Output Directory to Copy if newer.
This means you would have to add these changes to the csproj as well.

What's the difference between a dll and nuget package?

First of all, I apologize if this is a basic question. I tried looking this up, but for some reason, I got more confused. So, I decided to ask here. Is a dll file and a nuget package the same? Are they both just being referenced in the project?
When you add features to your project via a nuget package, you're just adding files to your project. It can be javascript files (like jQuery), DLLs that your project references (like Newtonsoft JSON), or a whole bunch of things (like Entity Framework or Owin/SignalR) -- anything really.
The advantage of using the nuget package system is that it tracks it all for you. It notifies you if your added packages received an update, it removes the files and unreferences them if you take the package off your project. It handles all of that for you, so you don't have to track the files that the nuget package added, place them in special folders, make sure they get copied in your builds, all that micromanaging stuff.
From the docs, https://www.nuget.org.
"What is NuGet? NuGet is the package manager for the Microsoft
development platform including .NET. The NuGet client tools provide
the ability to produce and consume packages. The NuGet Gallery is the
central package repository used by all package authors and consumers."
A package can contain one or more dlls in addition to other assets such as config files etc.
You can add libraries via reference into your project but you would not notice when they were updated.
NuGet is a Visual Studio extension that makes it easy to pull in not only libraries but components, and most importantly their configuration into your visual studio project. It will help you manage your packages installed on your project and it will notify you when the package has new version released.
Let's say I created my own DLL, I could add my own DLL by reference. However, it won't be available in NuGet until I package and publish it first to make it available at the NuGet Package Gallery.

Adding a NuGet package to a project without Visual Studio

I'm trying to automate adding NuGet packages to project on a remote server that doesn't have Visual Studio (nor any build servers) installed. I do know how to use NuGet.exe from my C# code, but this executable only downloads packages and doesn't do any other required work (adding references, executing ps scripts etc). What do I do in order to fully install a package?
Note: I don't need to update a package for my own app, I need to add a package to an arbitrary .csproj file on the server. I'm building a Web-based .Net IDE, and need my users to be able to add packages to their projects.
I see two possibilities: one is using some kind of functionality not present in NuGet.exe, but ratherin some other library (maybe a VS addin), but I don't know where to look for it. The other is to simulate some kind of NuGet Powershell console and send commands to it, but again, I don't know how to do that.
You might want to consider SharpDevelop.
Installing NuGet Packages outside of Visual Studio an article about the functionality you are trying to achieve (written by Matt Ward, one of the project contributors) says:
Since NuGet uses PowerShell the simplest approach was to extend the
existing PowerShell cmdlets included with SharpDevelop. Now you can
write a few lines of PowerShell script to install a NuGet package into
a project that has never had a NuGet package before, have the project
itself updated and any package PowerShell scripts run. All this from
the command line without Visual Studio open.
Just to add an additional answer in-line with Alex's post about SharpDevelop, you have a couple different options.
Use Nuget.exe (Related Blog post)
NuGet Addin for MonoDevelop and Xamarin Studio (see GitHub)
ASP.NET Pages using WebMatrix (see this video)
All of this info is from the Nuget FAQ.

Categories