I'm trying to migrate all my C# projects to new Nuget Automatic Restore, following this tutorial: Migrating MSBuild-Integrated solutions to use Automatic Package Restore
I've successfully done it to my desktop/libraries projects, which I had to edit .csproj files, removing these lines from it (I'm not using TFS):
<RestorePackages>true</RestorePackages>
...
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
...
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
However, WebSites don't seem to have any .csproj or any other file containing these instructions. When I install a package, it sucessfully put the .dll inside my packages folder, but it also put in bin folder. If I select the .dll under /bin within Solution Explorer, it has the following properties:
Auto-refresh path: C:\mypackages\Newtonsoft.Json.6.0.8\lib\net45\Newtonsoft.Json.dll
File Name: Newtonsoft.Json.dll
Full Path: C:\MyWebSite\Bin\Newtonsoft.Json.dll
This is set default when I first install a package from nuget. I think it should not look into bin folder, or when I build the project, it should bring the .dll to bin folder if it doesn't exist. The problem is if I build the project without the .dll in bin, it gives me the following error: "The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?)". For desktop/libraries projects, the .dll is copied to bin folder.
I read in another question Nuget doesn't support WebSite, but Web Applications instead: NuGet Package restore for website, but I also read in Nuget's page that they have added compatibility to ASP.NET Web Sites, so here is my question: Am I doing something wrong? Or should I migrate to Web Application because they don't support Web Sites at all?
I also have the same problem described in the above question. I was wondering if you figured out how to do a nuget restore on the website without the project file. I do have a package.config in the website.
I tried a bunch of different things and the following command got me closer to a resolution, but not quite.
nuget restore packages.config -PackagesDirectory ..\packages
The above command does restore the packages into the ..\packages folder as expected, but I cannot figure out how to get the correct assemblies into the website's bin folder.
When you click "Enable NuGet Package Restore" in the right mouse button context menu on the solution in Visual Studio you get an info message shown which says:
Packages installed into Website projects will not be restored during
build. Consider converting those into Web application projects
necessary.
However there is a workaround I tried that works. Consider situation when you have a class library (DLL) project referenced by the Website project. If both projects reference the same NuGet package, then building whole solution the DLL project is built first, packages are restored correctly. Next step when it comes to the Website project the required package is already in place and its DLLs are copied into /Website/Bin/ folder according to the *.refresh file. Result - solution build finishes successfully.
I can definitely confirm that NuGet automatic restore feature actually works for Web Sites projects under VS with latest version of NuGet.
Make sure that:
You are using NuGet 2.7 or higher (Tools > Extensions and Updates > Updates)
There is no .nuget\NuGet.targets file at the solution root
You have packages.config in Web Site root with all references to the packages (normally generated by VS when adding NuGet packages)
Visual Studio is configured to "Allow NuGet to download missing packages" and "Automatically check for missing packages during build" in Visual Studio (see Options > NuGet Package Manager) - these are ON by default
Here what I see as the build output when some package for Web Site project is missing.
Restoring NuGet packages...
To prevent NuGet from restoring packages during build, open the Visual Studio Options dialog, click on the Package Manager node and uncheck 'Allow NuGet to download missing packages during build.'
------ Build started: Project: WebSite1, Configuration: Debug Any CPU ------
Validating Web Site
Building directory '/'.
Validation Complete
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
Link that describes the above in details: https://docs.nuget.org/consume/package-restore.
Here is the solution to this problem and it does work.
If you have a separate business logic layer, you could install the nuget packages into that project. Then you can do the nuget restore on the business logic layer prior to doing msbuild on the website solution. When doing msbuild on the solution which contains the BLL and the WebSite it will pull all the referenced assemblies (including the nuget restored dlls) out of the BLL project into the website's bin folder.
Here is a hack option if you don't have a separate business logic layer.
Using NuGet with *.dll.refresh files in ASP.NET "Web Site" projects with Web Deployment Projects
Related
I have a project on ASP.NET Web API that has references to many libraries. When we tried to do our usual CI/CD to the App Service via Deployment Center. We faced with issues.
We need to remove .csproj in order for the deployment to work else we are facing this error on server
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105.
However we require the csproj files for the various members in the team to work together for this particular project.
In this case, what is the likely solution that we can adopt?
Problem: The source control will only contain references for the binaries. The packages should be restored before a build can be triggered.
Fix: Add a step in your CI/CD to restore the NuGet packages in the project before you trigger a build. Ref attached image.
In the company I work, inside every solution we have one folder packages, which contains all dll dependencies. This folder is not in repository with the rest of the solution.
Every time I build one project, all files inside folder packages are restored and any missing dlls appear again. This happens in the beginning of the build, no matter if the build succeeds of fails. Even if the project has no dll dependencies, any missing dlls in packages are restored.
I suspect it is a setting in msbuild but I cannot find it. Does anyone know where it might be or if there is a place with msbuild *.targets files?
thanks for any help
This is because Visual Studio restores packages defined in the packages.config files.
You can control this behaviour in Visual Studio in options:
From the MS Docs regarding regarding Nuget:
MSBuild: use the msbuild -t:restore command, which restores packages
packages listed in the project file (PackageReference only). Available
only in NuGet 4.x+ and MSBuild 15.1+, which are included with Visual
Studio 2017. nuget restore and dotnet restore both use this command
for applicable projects.
Further down, there's quite a bit about enabling/disabling and modifying this behavior in a variety of ways.
Allow NuGet to download missing packages: controls all forms of
package restore by changing the packageRestore/enabled setting in the
NuGet.Config file as shown below (%AppData%\NuGet\NuGet.Config on
Windows, ~/.nuget/NuGet/NuGet.Config on Mac/Linux). In Visual Studio,
this setting allows the Restore NuGet Packages command on the
solution's context menu to work.
Appearing to be more to your issue:
Automatically check for missing packages during build in Visual
Studio: controls automatic restore by changing the
packageRestore/automatic setting in the NuGet.Config file as shown
below (%AppData%\NuGet\NuGet.Config on Windows,
~/.nuget/NuGet/NuGet.Config on Mac/Linux). When this option is set,
running a build from Visual Studio automatically restores any missing
packages. The option does not affect builds run from the command line
using MSBuild.
I have some issues with my VS2017 csproj's(https://natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/). When I install certain nuget packages, I'd get some additional files being added to my project and most of the time the dependency is not even working properly. It does not do that on older csproj's.
Two examples:
I have one "home made" nuget (made out of a VS2017 csproj too) which is supposed to transform the local app.config of the target project on install and uninstall (basically adding a line on install and removing it on uninstlal). On a older csproj, it does what it needs to do. With a VS2017 csproj, it will not do the transform but add the two transform files to the projects.
I need to install the package named "CefSharp.OffScreen" on one of my projects. On an older one it works like a charm. On a VS2017 csproj the dependency is not even there (it has a "!" in front) and it adds two "x64" and "x86" directories with tons of files ("dll's" etc.) in there.
Is there something known about issues like that with VS2017 projects ?
Thanks in advance for the help !
Is there something known about issues like that with VS2017 projects ?
For the first example, That because xdt transforms aren't supported in PackageReference environment. This includes both sdk-based projects as well as classic .net framework projects using PackageReference instead of packages.config. You can follow this GitHub issue for more details. There is also a sample package that shows how to use build-time logic to apply transforms instead to work in all environments.
For the second example, you can find a CefSharp.Common.targets file in the \build folder in the dependency package CefSharp.Common, in this .target file, you can see following code:
<ItemGroup>
<CefSharpCommonBinaries32 Include="$(MSBuildThisFileDirectory)..\CefSharp\x86\*.*" />
<CefSharpCommonBinaries64 Include="$(MSBuildThisFileDirectory)..\CefSharp\x64\*.*" />
<CefSharpCommonBinariesAnyCPU Include="$(MSBuildThisFileDirectory)..\CefSharp\**\*.*" />
</ItemGroup>
With this .target file, nuget will including files under the x64 and x86 folder to your project.
In the old .csproj project, that .target file imported by following code after install the nuget packages, you can check it in your project file .csproj:
<Import Project="..\packages\CefSharp.Common.63.0.3\build\CefSharp.Common.targets" Condition="Exists('..\packages\CefSharp.Common.63.0.3\build\CefSharp.Common.targets')" />
Those files under the x86 and x64 folder would be imported when the project is running.
When you use the new .csproj project, the .target file imported by the file project.assets.json, all the files will be imported to the project when you save the .target in the project.assets.json.
That is the reason why you got those tons of dll files after install the package package CefSharp.Common. So, this is not a issue, but because they import .targets in different ways.
If you do not want show those dll files in your project, you can return back the packages.config.
Hope this helps.
When I try to compile my program I get the following error:
This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=317567.
Now when I right click on the solution and press
All packages are already installed and there is nothing to restore.
I tried manually reinstalling every package which didn't solve the problem, I tried reinstalling NuGet but that didn't help either and I even tried reinstalling visual studio.
I also tried moving the package folder from the tfs folder to overwrite my package folder but that didn't solve anything. I also tried redownloading them with this package missing, that didn' t solve the problem either.
Anybody know how to restore the nuget packages?
Use Package Manager Console in Visual Studio to run this command.
1.This will restore all packages from solution
nuget restore YourSolution.sln
2.If you want to reinstall the packages to the same versions as were previously installed
Update-Package -reinstall
Honestly, whoever developed the NuGet command for VS needs to go back to the drawing board. They totaly missed the fact that sometimes these DLL(s) and/or files get corrupt or deleted. a "NuGet Get-Packages -Force" option would really save their bacon. The only GAP I see is that VS and the Package console does not allow you to invoke a forced download from NuGet. Even clearing the cache via VS is useless.
I ran into this issue when I tried to build my project on a computer where the packages-folder did not already exist in the solution root.
When the project file was initially created, it seems VS2019 added the following into the project file:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
</Target>
From what I understand those settings are deprecated nowadays, no idea why VS inserted it in the first place.
Anyway, after removing those lines VS restored the packages and built the solution correctly again.
It's probably a good idea to clear the Nuget Cache by deleting the contents within this directory: C:\Users\{your_username}\AppData\Local\NuGet
All you need is that:
Open the Package Manager Console and run this command: Update-Package -reinstall
P.S: VS2017 and above NuGet Package Manager is included with Visual Studio, no need to install anything else.
The problem with the functionality of the NuGet package can also be caused by the fact that NuGet package is requiring certain dependency that the project does not meet.
NuGet package can have a declared dependency in Dependecies section, e.g. .NETFramework,Version=v.4.6.2 while the project is targeted to an older version (Target framework: .NET Framework 4.6.1.).
Instead of the NuGet system notifying the user of this fact, the project simply does not compile.
In my case, I have different Nuget configurations, and somehow the HintPath in the project file didn't fit.
Maybe you should check if the HintPath leads to the right NuGetPackages folder.
You should also check the following entries at the top of the file:
And at the bottom of the file:
All these paths should point to the right NuGetPackage folder in your file structure.
In my case the problem was solved by deleting the "obj" folder(s) and then rebuilding the solution.
The "obj" folder had several NuGet related files that still referred to version 0.0.2 of a package while all projects in the solution were already using version 1.0.0 of that package. Building the solution failed with the error message "package with version 0.0.2 could not be found". The solution with build folders included was recently copied from another machine.
Well it's probably a bad way but I found that it works if I just delete the line
http://go.microsoft.com/fwlink/?LinkID=317567." HelpKeyword="BCLBUILD2001" />
from the project.csproj , not sure if this is going to cause problems later on but it works for now.
For a github hosted open sourced C# project which is also available via NuGet, how should one organize the source? Specifically:
should the .nuspec file be in the github repository?
should the .nuspec file be in the same folder as the .csproj file?
how about the NuGet package tree (the /lib, /content stuff), since is generated, should it be in git?
My thinking is that the NuGet part is separate from the github hosting, as in the project source are available but the .nuspec is not, since the publishing in NuGet is not an open source operation per-se. None wants that every fork to build and publish a new NuGet package, so that the open source Foo package ends up in the gallery as 'Rick's Foo' vs. 'John's Foo' vs. 'Alice's Foo' etc.
But on the other hand I do want the github source depot to act as a one-stop repository for the project, if I open my other laptop and enlist from there, I should be able to build/package/push w/o recreating the whole NuGet infrastructure from scratch (ie. only enter my API key, nothing more).
These two requirements are contradicting each other, Did I miss something obvious?
I would do the following:
Commit the .nuspec file next to the .csproj file
Add a nuget.config file which moves the packages folder a level up.
Enable package restore in the solution and do NOT commit the content of the NuGet package repository
Create an msbuild file (or whatever build vehicle you like) which has:
a "build" target which builds the source and creates the nuget package
a "publish" target which pushes the NuGet package to nuget.org and takes your API key as a parameter.
I personally maintain the version number of the nuget package in the .nuspec file and manually update it when I do a "release". This way I can tag the exact release I pushed to the NuGet feed.
With this setup a build in Visual Studio does not produce a NuGet package but all tools are available in the repository to do so.
The Folder Structure looks like this:
.\Docs\ ==> not in source repo
.\Packages\ ==> not under source control
.\Src\ ==> git repo here
.\Src\MySolution.sln
.\Src\.gitignore
.\Src\MuRules.ruleset
.\Src\build.proj ==> msbuild file to build everything.
.\Src\MyProject\MyProject.csproj
.\Src\MyProject\MyProject.nuspec
.\Src\MyProject\nuget.config
.\Build\ ==> not under source control
.\Build\Debug\
.\Build\Release\
.\Build\Publish\
Be aware of this bug in the Package Restore feature, it will ignore the packages location you configured. http://nuget.codeplex.com/workitem/1990 ==> This is fixed in Nuget 2.7
On nuget v2.8, I just need to modify .gitignore and add:
packages/
This will exclude the nuget packages folder from committing. When you build the new checked-out source code, the packages would be downloaded and restored. Make sure package restore setting has been enabled but I think it's been enabled by default on v2.8.