We're building a set of several services, each service has it's own solution with associated projects. Many of these services rely on the same NuGet packages.
All the solutions have "Package Restore" enabled.
Some of the solutions refer to assemblies owned by other solutions, this is one obvious reason why we need all the solutions to refer to exactly the same versions of different NuGet Packages.
All of the services need to work together to achieve an end result. They're packaged and installed as part of a single product, which is another reason we'd like everything to be running off the same versions of the NuGet Packages
We're having trouble keeping package versions consistent between Solutions.
Currently we're manually checking and updating package versions, we're also getting occasional compilation errors because projects in one solution end up referring to different versions of the same package.
Is there a recommended way of doing this (hopefully an automatic process)?
Would we be better off without Package Restore?
Anyone have any general advice on the subject?
Thanks
Update: I created an issue for this on the NugGet project http://nuget.codeplex.com/workitem/2623
To solve this:
Create your own private NuGet server (see 1 and 2) that hosts the correct versions of the packages you use.
Configure each build system to use that server and auto update to the latest version.
Although this requires a server, it not only ensures everyone has the correct version but speeds up the downloads for build servers as well.
You could configure your TFS builds to update all NuGet packages in the solution to their latest versions using the nuget update command.
The latest versions could be from nuget.org, a local NuGet server or even a network share. Use the source parameter to define the sources you want to update from.
You can perform the build configuration via MsBuild proj files or via a TFS template.
Related
Unfortunately, we have projects with different nodejs versions. I am not sure if this is like java where I can have multiple jdks installed(multiple nodejs installed) and each project magically uses the correct version via a config file? Also, most commands in tutorials are not including version numbers when installing tools and libraries like so
npm install -g expo-cli (tool)
npm install #react-navigation/native (library)
Coming from gradle with the gradle wrapper where everyone on the team uses the tools and library versions defined in the build.gradle file, this is odd to me. In the gradle world, everyone on the team uses the same exact version of gradle(gradle itself ensures if one person upgrades it in the repo, everyone gets the upgrade and stays in sync on the same version). Then there is plugins/tools and those versions are defined and then libraries and those versions are defined.
How do I guarantee everyone is using the same npm, node, expo, etc. tools?
How do I guarantee everyone is using the same libraries?
How do I guarantee everyone is using the same typescript?
Ideally, we upgrade any of these in the repo + any fixes to the upgrade so on checkout, developers start using the new tool + new *.tsx files so it is seamless much like in the gradle world. In gradle, I upgrade the
version via a property
versions of plugins/tools
build.gradle files
any source code files
and check that all in as a unit such that any developer that checks out is using all the correct versions together. I want this in react-native for our ios/android mobile project or as close as I can get.
I have hacked things before as in installing 'ant' into the git repo and this worked wonders(even though it is such an ugly hack) and everyone used the tool in the repo instead of the one on their OS. Perhaps there is a way to do that?
A bloated repo with binaries was worth it's weight in gold to prevent version compatibility hell as people upgraded libraries over time. NOT only that we found that tool bugs were easier to track down as we could revert the repo. NOT only that, we could reproduce builds form 1 year ago as the tooling was reverted where todays npm tools can't build the 1 year ago thing due to all the changes. The advantages just kept piling up and up and I can't even remember all of them.
Tooling running from the repo either via bootstrap like gradle wrapper or full blown thing is generally the best option until the full blown thing is really bloated but even then locking it to a hash on another tool repo could be better
Any ideas welcome here to put my team on all the same tooling(works great for people joining the company or team from another project as well to not have to install much).
thanks,
Dean
Typescript and libraries should be taken care of by removing any carets and tildes in your package.json and specifying exact versions.
One low overhead possibility for the rest could be shell scripting and a private package repo. You could host the versions you want to install internally, and get it all through cURLs.
Or you could add some simple scripts in your npm pre-install, for example nvm use 12.2.1 should, through error messages, guide the user to installing nvm and using the proper version.
What is the best way to handle specific version of libraries while using MonoDevelop (precisely - use ServiceStack v3 instead of ServiceStack v4)?
Unfortunately, MonoDevelop's addin NuGet does not allow specifying package version (no Package management console support). I've tried hacking it in .csproj and package.config file but it does not work entirely well and it seems to be smelly solution.
One obvious solution is to get rid of NuGet and reference libraries locally after manually downloading them.
How would you solve this problem?
Thanks for all responses :)
Being able to add a specific version of a NuGet package with the MonoDevelop addin is on the todo list.
If you have access to Windows you could use SharpDevelop to add a specific version using its Package Management console.
Or as you have suggested, edit the packages.config file, then restore the packages. However you will need to add the required assembly references by hand. This option is not that bad if there are not that many assembly references and you are not going to be updating the NuGet package very often. Although the benefit of this approach over downloading the NuGet package, extracting it, and directly referencing the assemblies is equivalent and the same amount of work. Also doing it this way you can more easily update the references by simply dropping the new binaries into your lib folder.
Or you could change the source code of the addin. I thought about adding a simple text box where you could specify a particular version. Ideally the dialog would give you a list of available versions.
I would probably just download the ServiceStack assemblies you need and directly reference them.
Our small, distributed team uses a NuGet package in a project. That package has a bug in the current release. Unfortunately the package does not publish debug symbols and source, so I grabbed & built the latest source, removed the project via NuGet and added a (temporary) reference to the project I just built locally.
Turns out, the issue is fixed in the latest code base.
This particular project only seems to release updates on NuGet every 6 months or so.
Until that next release, our team needs to use the code version where the bug is fixed.
One option certainly is to check the source code into our source code repository and keep the project reference (rather than a NuGet reference), essentially treating it as an internal utility project.
That feels "old school" though.
Is there a better way to manage this situation, using the NuGet infrastructure?
One option is to create your own NuGet package with the updated code. Then add a new Local Package source (just create a file share and place the .nupkg file there). Move the local package source up higher in priority than the official one so NuGet will use your package before looking online.
In fact I recommend copying all NuGet packages to a local repository, especially if you use package restore. This way you are not dependent on nuget.org to be up all the time (there have been several instances of downtime).
The one drawback is that when an updated package is finally published to nuget.org, Update-Package will not pick up the new one unless you specify the package source.
Anyway this will allow you to continue to use NuGet while waiting for your updated package.
I will explain this as best I can!!
I have a large project with a build that kicks off automatically after each checkin. This normally works fine, but this is the first time I have attempted a build that has included code using a library other than those already in the solution.
I have added the Microsoft antixss library (I got it through nuget on my local dev machine). When I checkin, the build fails as nuget on the build server is having trouble getting out to nuget through our proxy.
Obviously the best solution is to get this issue resolved, but it brings up a question of resilience - if our connection to the outside world is mashed, can I not do any builds?
This led me to thinking, is it possible to add libraries such as this antixss to the defaults that always appear in my build servers packages (like jquery etc?). Each build, this packages folder is cleared and replaced by the build process. At the moment, every-time I build the build breaks due to the proxy issue.
I really need to get a release out today, so was wondering if anyone could help me here? It seems silly that I need to go out to Nuget as the library exists on my local!!
Many Many thanks
Install your own nuget server behind the firewall/proxy and point to that as your default NuGet server.
I've used the free version of ProGet in the past as an easy to run a nuget server that also acts as a caching proxy for the main nuget gallery. It also means that if the main nuget server or your internet connection is down you will still have a nuget server that your build can connect to.
I have a c# project, that is using nuget-packages, for instance "System.Data.SQLite".
When I build my solution, the project is built each time.
Looking into details, it turns out that the DLLs that belong to packages (that are located in
$(SolutionDir)\packages\$(PackageName)\
) will be renewed before each build, although there is no new version on the server. This results into this each-time-building.
How do I avoid this?
Upgraded nuget.exe to v2.7 solved the problem