I am still confused about how nuget works. I git clone a C# .sln project and from console, and I ran this nuget command:
nuget restore my_project.sln
it came to my attention that it generates two packages containing all dependencies required by my_project.
One package is located under my_project/src/packages, the other c:/users/my_user_name/.nuget/packages. While the file structures are a little different the DLL files in both packages are identical.
That confused me. Why two packages are generated by default? Where exactly does Visual studio look up for the project's dependencies?
More important, which config file should I update in order to only keep a copy of the dependencies and how can I specify the location in my file system for the packages?
Recent versions of NuGet support package references in project files.
This format will restore packages on demand, using your %USERPROFILE%.nuget folder as a cache. And your solution folder won't be "polluted" by a packages folder with binaries that you probably don't want to commit to source control.
VS2017 allows you to select "PackageReferences" or the older "Packages.Config" format when you create new projects (Tools/Options/NuGetPackageManager/General).
You probably have some projects in your solution that use the older "Packages.config" format, which stores in the packages folder in the solution directory, and newer "PackageReferences" format.
To convert the older projects to the new format, I believe you need to remove all packages from the project, then add them back again. They will be added using the default format you selected, with a prompt for confirmation if you selected "Allow format selection on first package install".
Related
I am working on a .Net application and planning to use SQLite as its back end.
I ended up with “Not able to load SQLite.Interop.DLL”
Then I found the documentation in http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
But I’m not able to find a zip that contains all the essential files mentioned in the above documentation. All the files are either separated or in NuGet packages.
Can someone help me out to find a zip the contains the following DLL files as a zip in a single zip ?
<bin>\System.Data.SQLite.dll
<bin>\System.Data.SQLite.Linq.dll
<bin>\System.Data.SQLite.EF6.dll
<bin>\x86\SQLite.Interop.dll
<bin>\x64\SQLite.Interop.dll
I don’t want to reference a NuGet package with my project, as I’m building this application using ANT and signing this is a separate build server that I’ve setup to compile and check the MSI files and it’s generation.
I’ll add a copytask to my ant build and copy all the dll files to the project before building it into msi. The only thing missing is a zip that contains all these above essential files.
PS : I need this application to work on both x86 x64 arch.
I've Searched around almost many sites and like #Blindy and #Selvin said there is no way around NuGet packages it seems.
Hence, I've downloaded the NuGet package from http://system.data.sqlite.org/downloads/1.0.113.0/System.Data.SQLite.Core.1.0.113.0.nupkg here which seems to contain SQLite as well as Platform Interop files.
Once I've downloaded these,
In VS, Tools -> Options -> NuGet Package Manager -> Package Source -> Added a new source as my local folder.
I've placed the downloaded package inside this folder
Project -> Right Click -> Manage NuGet packages -> Under the browser tab, I've selected the RHS filter as the source I've added in the previous step and the package I've downloaded was listed under here.
I Installed them and this created a packages folder inside my solution directory.
Then I was able to use System.Data.SQLite in my application. But it still threw "Could not load SQLite.Interop.dll". To tell the builder that you have to use the interop files, open the csproj file for the project and add,
<ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles>
And then this started working properly. I might use this as a structure instead of running a copytask in ant I guess.
Thanks to #Selvin and #Blindy
I need your help.
I'm developing an msbuild task that performs certain actions upon msbuild.
I want my users to be able to download and install a nuget package and once the package is installed the build task will be part of the build process.
I know how to release a nuget package and i know how to includes a custom targets file together with the nuget, what i don't know is how to add the import statement to the csproj upon nuget installation:
Is there a way to do so or am i asking for too much?
Thanx!
Gilad
The docs aren't in the easiest to find place, but here's a link to the docs on including MSBuild props/targets files in your package.
Basically, you put the file in the package in the location build\<tfm>\<package_id>.props. For example build\netstandard2.0\MyPackage.props. If you want your build targets to be included in all TFMs, you can use build\<package_id>.props, but if your package also contains other assets like lib/ or contentFiles/, the "no-TFM" build files will cause "asset-target fallback" to fail, so if your package has only net472 libs, and the build files, a project targeting netcoreapp3.0 will get only the build assets, none of the net472 assets. If your build files are in a TFM folder, then NuGet's asset target fallback will select both the lib and build assets. So, I strongly encourage everyone to always use the TFM folder.
The docs need to be improved, but the table explaining lists build, buildTransitive, and buildMultiTargeting. Projects using packages.config only use build assets under build. Projects using PackageReference only use build and buildMultiTargeting assets when the project references the package directly. Assets under buildTransitive get selected when the package is pulled in transitively, rather than directly. The difference between build and buildMultiTargeting is complex. If you understand the concept of "inner-build" and "outer-build" in multi-targeting SDK style projects, that's the difference (build is inner-build), otherwise only use build.
I should update the docs to have this information.
I have my windows forms application with WindowsAPICodePack but i don't know where should I put the package in the release folder, and without it the program just gives me an error (it's in Hungarian so I don't think anybody can understand, but it said that it can't find the windowsAPICodePack, the version number, culture and publickeytoken) on another PC, on mine it works.
Depending on if your application is using a packages.config file to manage packages or if your project is using package references (PackageReference) will determine path to solution.
When a package is installed it records the package identifier and version into the project file or packages.config file in your solution workspace.
If using a package.config to mange packages then ensure your packages are getting installed in the location as expected, possibly clearing the cache will help to ensure proper version is installed.
find out the packages folder where your application is trying to load the references.
Possibly config binding redirects.
Clear you package cache and reinstall. use the package manager ui for your ‘debug’ and ‘release’ MSBuild configs to ensure the package is being referenced correctly.
Verify your nuget.xml settings file for locations of packages
Read all the version or property values to use for your application. Ensure you are configuring the release target as expected.
Here are some links to help you config the correct setup for your approach:
Package reference via project files
if using - Packages.config settings
Config setting for Nuget
NuGet settings
Note: for simplicity if this is just a school project then just remove all NuGet packages references and find the dll . Then just add reference to dll and check the property to include in output . This will give you a simple folder with all the files needed to run your app from pen-drive
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.
We have a .csproj that is being worked on by a number of people.
Unfortunately nuget has installed its 'packages' in different locations on each users machine, meaning when another user does an SVN 'update', their project wont compile because the .csproj file's 'hintpath' element is pointing to the dll in a different location.
Are there any other solutions to this?
Use NuGet packages restore feature and don't commit packages to source control.
This allows NuGet client application to download packages on demand. Downloaded packages will be located in solution folder, so, references to packages content will work at any machines.