I'm currently using EF7 - beta4 and would like to use beta6. I know I'm playing with fire by using nightlies, but has anyone else done this and have been able to build after upgrading?
I've added the nightly nuget repository: https://www.myget.org/F/aspnetvnext/api/v2/ but when ever I upgrade a package it totally trashes all of .net in both DNX 4.5.1 and DNX Core 5. Now I'm not crazy enough to do this in a working project, so I'm testing this out in new empty mvc project and when I attempt to build I get in excess of 2000 errors from everything.
Has anyone else attempted this and if so how does one get around all the errors?
The nightly builds are highly unstable. Here are some pointers for working on the bleeding edge of ASP.NET.
Reset all packages. Sometimes nightly builds break other packages. Delete project.lock.json and delete all packages (~/.dnx/packages/). Reinstalling may help you get a coherent set.
Upgrade DNX. dnvm upgrade -u. This installs the latest, unstable version of DNX.
Submit issues. If it's breaking for you, it may not just be you.
Pay attention to the ASP.NET on GitHub. Nightly builds are usually only a few days behind the latest changes to the dev branch. We are working fast, and breaking things.
If stability is important, stick to the Nuget.org betas. Beta5 was just released yesterday, and has been more thoroughly vetted for stability.
Watch the Announcements repository to receive a heads-up on breaking changes.
Related
We have an .Net 6 API.
We have our own Nuget server to ensure we have backup of used Nuget packages so we always are sure we can run our CI chain.
After the upgrade to .Net 6, then every time MS publishes a new version of any of these three assemblies then our CI builds fail, because our NuGet server doesn't have the new version.
Microsoft.NETCore.App.Runtime.win-x64
Microsoft.AspNetCore.Runtime.win-x64
Microsoft.WindowsDesktop.Runtime.win-x64
Latest with 6.0.8. We then have to download the new packages to our Nuget server and then everything works.
In general I would like us to keep on known versions all the time, and only change referenced package version on purpose - and not just because developers publish new versions.
But I can't find any explicit references to these three packages.
Does anyone know where they come from - and more importantly - are there any way to lock our solution to use e.g. 6.0.8, until we decide to upgrade next time?
Best regards
/Anders
My company has internal components that we deliver via internal NuGet. Now i want to make a Version 5.X of these components which will be breaking a lot from the 4.X versions.
However now if my colleagues browse for updates, the Nuget browser would recommend these new packages.
What i would prefer: If example 4.6 is installed, it would take the highest 4.X version but not 5.0 or above. Making packages for the 5.X path under completely different names would be annoying when the developer choses to upgrade.
Is there a way to mark nuget packages to do something like that? If that's not clear, tell me and i try to clarify.
If your projects are using packages.config, you can use allowedVersions: https://learn.microsoft.com/en-us/nuget/reference/packages-config#schema
There's no way to do this if your project uses PackageReference, but you can upvote (👍) this isse: https://github.com/NuGet/Home/issues/9082
now that they release v0.5.0 the question is how can I upgrade from 0.4.6 to 0.5.0 without loosing all my packages? is there even a way. Or if there is no easy way, how have people done it? What is the best way to do it?
Other question is, is it worth it or do I need to upgrade? What are the benefits or why I should not upgrade (yet)? Is there problems with Atom and other packages?
Yes there is quest same question already, but it is for older version and I thought if something has changed on upgrading.
You can go into your .julia/v0.4 folder and copy the REQUIRE file to the v0.5 folder. Then when you Pkg.update() your packages should automatically install.
There are very many upgrades (broadcast syntax, arraypoclypse, string changes, etc.), and many packages may stop supporting v0.4 for this reason. I would recommend you start upgrading soon. Juno has already released its v0.5 version, so when you update it should be compatible.
I understand that NuGet packages update process is not automatic for a good reason (a new version could break your code or cause unforeseen problems), but then it transfers the responsibility of updating all packages to the developers themselves. When exactly should we be updating NuGet packages for a given project? Are there some guidelines regarding this process?
In our current project, this is more or less arbitrary: I update packages whenever I remember to check for updates, and preferably at the start of a sprint so that, if there are problems with the newer versions, we are able to fix them or rollback to the previous versions of the offending package. Most of the time, I'm the only developer that worries about this stuff, but I feel it is valuable to always be as up to date as possible because of performance reasons and new features that can make our work easier.
Well, you should update whenever you are able to cope with it.
So you need to think carefully about the regression updating the packages could cause to your application if already in production, or the extra tests you are going to need to carry on in order to verify everything seems to be working as expected.
Normally updating to newer minor versions shouldn't cause much problems, but you always have the risk of it. Looking at the newer version release notes could prepare you to what to expect of the update.
In summary, update when you can cope with it, and you are ok with any shouting from your testers if suddenly the system regress without them even knowing it was coming :)
Few tips to decide package update strategy:
Don't run production application on a deprecated (not-maintained) package version. Upgrade to a maintained version at bare minimum if unable to upgrade to latest.
Don't run production application on a pre-release (not-stable) package version. Upgrade to a stable maintained version.
While upgrading by a major version, read publisher's release notes to understand the implication backward-compatibility from application context. This will help put a better estimate on development and testing efforts.
I am upgrading my server from an old version of Mercurial, 1.5 to the newest version. I am wondering if the 2.2 build of Mercurial is stable for use by multiple users at a time. Also are there any gotchas when upgrading like my custom hooks not working, or a buildslave object not working? I have not done a major upgrade on a source control server before so help would be appreciated.
Mercurial is famouse for being very strict regarding compatibility. Have you checked upgrade notes? It list all breaking changes between version. Biggest change for me is introduction of hgweb in 1.6.
Biggest exception from compatibility rules are hooks. Mercurial doesn't guarantee anything so only way is to try.
Also consider making update in two stages. For example first to 1.9 and than to 2.2.