At my work place, we are not allowed to install packages from Nuget, so I am just wondering is there any place to download installer instead, so an internal packaging team can distribute it across the firm.
And is the package production ready?
Unfortunately, Microsoft.Bcl.Async is only distributed via NuGet. You would need to use the package manager to get the assemblies, though you could then just copy the assemblies manually into your system.
And is the package production ready?
Yes, it is now production ready. The BCL Team just announced that this package is now considered Stable. From their post:
Being stable means the owner of that package states that API and functionality are unlikely to change and therefore suitable for use in production.
You could just download the package from another PC (out of work) and then copy the assemblies. Of course you don't get the extra benefits from NuGet, but it's still a viable option.
EDIT Just saw that a few days ago the package was declared stable as Reed correctly indicated.
Related
I'm looking for a simple way to manage NuGet packages for the whole solution, to prevent conflicts between transitive NuGet packages when assembling all files into one installer.
When building a project all direct and indirect dependencies are analyzed and the NuGet resolution picks up the best matching version for each NuGet that is at least the same version as the lowest version and might also create binding redirects if necessary. (all good and fine)
The problem we have lately encountered was when we build the whole solution (200+ projects) at once, the resulting NuGet versions between all top level projects might not be identical. And due to the fact, that all resulting DLL and EXE files are installed into the same program files folder, the application can and will crash at runtime due to version mismatches when loading assemblies.
To better understand this issue I've created this sample repo.
The dependency graph looks like this:
Library1
Microsoft.IdentityModel.Tokens-5.2.1
Executable1
System.IdentityModel.Tokens.Jwt-5.3.0 (transitive reference: Microsoft.IdentityModel.Tokens-5.3.0)
Library1
results in: Microsoft.IdentityModel.Tokens-5.3.0
Executable2
Microsoft.IdentityModel.Tokens-5.2.1
results in: Microsoft.IdentityModel.Tokens-5.2.1
To demonstrate the problem, all projects compile to the same bin folder. When the whole solution is compiled and Executable2 is started, the application crashes, since the application expects Microsoft.IdentityModel.Tokens in version 5.2.1 but the actual version is 5.3.0.
For this constructed sample it is easy to find the problem and fix it with updating the Microsoft.IdentityModel.Tokens NuGet to the same version. (Manually, since Visual Studio Package Manager does not recognize this conflict in the consolidate tab).
But at a much greater scale it is far more complex to find those mismatches.
What we have found so far
Centrally managing NuGet package versions
Since it is not yet available, it cannot be used to solve the issue here.
Microsoft.Build.CentralPackageVersions
Unfortunately there is no IDE support for it, which makes managing NuGet packages very uncomfortable, which I would like to avoid if possible.
So my question is what is the best approach to avoid NuGet version conflicts between projects within the same solution?
We've experienced the same problem with some of our projects. We've been using Paket package manager since a couple of years and this has resolved that issue for us.
In short: you define on your solution level which packages you want to use in a file called 'paket.dependencies'. You can be very specific about versions, or let packet use the latest greatest. Then you can specify per project which NuGet package you want to use within that project in a 'paket.references' file. As the name implies, you reference to a package in the paket.dependencies file.
This will make sure, all references packages in your project will use the same package version. I hope this suits your needs as well.
First of all, I would like to clarify that I'm coming from a Java/Maven background.
I am managing Nexus and we have a team that are developing in .NET who are asking whether they can store exe files in Nexus under a Nuget repository. As this is not possible (and exe-s are not really artifacts as in "archives"), are Nuget packages a reasonable place to store exe-s? I would personally say "no", as, in my opinion, Nuget packages are supposed to just contain libraries and other resources, but as I'm not a .NET developer myself, I'd like to find out what the best practices are.
are Nuget packages a reasonable place to store exe-s?
If it's a tool, then yes. There are several good examples where Nuget is an excellent place to store exe-files.
For example:
The nuget package dotless has a tool (standalone exe), which is a compiler for CSS-files. This enables us to use that tool in our (TFS-) build server without installing any third party software on the build server.
But other than that, I agree with you. A Nuget-package is mainly for libraries and other resources that will be references in the project. But it's after all just a platform for spreading code between developers and different teams.
Or as Nuget puts it:
No matter what your package does or what code it contains, NuGet is
how you package that functionality into a component that can be shared
with and used by any number of other developers.
If the purpose of your nuget package is to deploy an executable program, then sure you can store an exe in there - what other option is there after all!
We are developing a WPF application at work which has various "common" dependencies (Unity, Prism, etc.).
It's all fine when adding new projects and then setting up the NuGet package dependency per project but when it comes to upgrades, it's really painful as it means we have to go through each and every project, delete the old references and then refetch the latest packages from NuGet.
Today for instance, I was tasked with upgrading Prism from 5.0 to 6.0 (which has breaking changes anyway) and this meant, in addition to fixing all the namespace conflicts, etc. that I had to go through every project, delete the old references, add the new dependecies and rinse and repeat.
My question is, is there a smarter way to deal with this problem or is this the standard approach?
Many thanks in advance,
Update:
I am mostly concerned with "major" upgrades which don't show up on the package manager. Version 5.0 -> 6.0 upgrade would be treated as a major upgrade and hence, would not have an automatic update applied to it in the NuGet package manager.
I don't expect NuGet to be able to do this automatically for me since such upgrades may (and often do) include breaking changes but I would like to know if there's a way to do the major upgrades less painfully than deleting the references from the projects and the packages.config for every project and then re-adding them using NuGet. For a relatively large project, this is very time consuming and I was wondering if anyone had a better way of managing such dependencies.
If you use VS2013 like you say, you can manage ALL your NuGet packages by right-clicking on your Solution and selecting 'Manage NuGet Packages For Solution'. This brings up a dialog where you can view all packages installed for all projects in the solution and all packages that have updates available. When you do upgrade the packages, VS takes care of all the reference changes required. If the package has breaking changes, then you're still on the hook for fixing those.
Disclaimer: I've never worked on a WPF project/solution but for Web/Forms apps, NuGet packages are handled this way.
I can understand your pain because i had the similar problem like you, but there is no easy way. but certainly you need to break the process differently of your daily development and your dependency update roll-out.
for the project i worked on, I use the common repository path that shared among the solutions that you work on, and you need to delete all the solutions folder references in order to get a clean state.
For each solution you work on you need to modify the property group that point to the common target repository (i'm using relative path)
Once all the things setup, you can actually perform an update with a script(I'm using python run-time script)
you can actually look at setting up common nuget-packages-folder for reference updates for detail, but it seems like what you looking at for the automate process
I had a similar problem when trying to upgrade multiple packages with alpha channel issues in Xamarin Studio, which also does not have the niceties of VS 2015 NuGet manager. I ended up writing a very simple PowerShell script that I run multiple times a day.
#
# This script updates local ibGib NuGet packages for mobileGib Android app solution.
# For convenience in copy+paste in manager console:
# ../UpdateLocalNugetPackages.ps1
Update-Package commonGib
Update-Package ibGib
Update-Package languageGib.Biz
Etc.
I believe you could tailor your NuGet commands to fit your needs.
Also, just in case you aren't aware of it, you should definitely read the NuGet command line reference. I may be mistaken, but it sounds like your scenario is doable with the Update command.
Should we put our nightly builds on NuGet daily? Customer asked for this but they are a big number of packages per year. Is NuGet designed for this purpose? How can we mark stable releases instead?
Thanks.
First of all, think from the users point of view.
Even if a customer installs your nightly, he will be able to go back to a more stable nightly if something breaks. For this an absolute requirement is a unique version scheme for every build that you publish.
Let's say your customer has version 1.0.1-nightly.1234 installed which works for hin. Now he does an update to 1.0.1-nightly.1235 which is broken and he can not continue. He should be a able do do
uninstall-package YourPackage
install-package YourPackage -version 1.0.1-nightly.1234 -pre
I understand that you don't want to mess up nuget.org with your nightly builds so you could either use another feed or setup your own sever (maybe your build server already can do this, I use teamcity which can do nuget deploys and has a build in nuget server, even if I never used it so far but am planning to do so).
Maybe you can do a monthly pre-release on nuget.org or manually publish nightly builds that you consider fairly stable.
I would suggest you change your version scheme to include a date in your builds 1.0.1-nightly.20140520 for your own feed and 1.0.1-nightly for the official build.
nuget itself supports versioning schemes like <major>.<minor>.<patch>-<buildname>.<revision> but nuget.org only allows <major>.<minor>.<patch>-<buildname>
http://docs.nuget.org/docs/reference/versioning
There is nothing stopping you from putting your nightly builds on NuGet. Some teams, such as the ScriptCS team and the ASP.NET team use MyGet for nightly builds instead of using the main NuGet feed.
You will probably want to distinguish these builds from stable releases, at least on the main NuGet feed. You would need to mark these builds as pre-release NuGet packages using a version number such as 1.0.1-alpha1 and use 1.0.1 for the stable release. However if you use MyGet you would not need to mark these builds as pre-release if you did not want to.
I'm looking to work on an application, an internal toolbelt if you will.
Rather than having users messing around with DLL's for the differing tools (they plug in via MEF) I was wondering if it's possible to jump on the back of Nuget?
I'd build the tools, package them as nuget packages and host them internally and the toolbelt application would then query the catalog, retrieve and extract etc etc.
Does anybody know of a way this is possible?
Chocolatey uses nuget as an underlying package manager to install applications on your pc.
http://chocolatey.org/
So I'm sure it's possible, but I've not done it myself.
The nuget documentation discusses a command line and power shell reference: http://docs.nuget.org/
Also linqpad, does something similar (in the paid for version), where you can include dll's from nuget. There is a screen shot on this page: http://www.linqpad.net/purchase.aspx