microsoft
NuGet 26.5 and 27.0 not available
It seems quite a few NuGet packages are missing from public sources Looks like
- All 26.5 packages are missing (e.g. Application)
- For some packages even 27.0 is missing (e.g. Business Foundation)
@SBalslev adding
Starting with version 27, we’ve changed the design for the NuGet packages slightly. In the past we published one NuGet package per app per country. We’re still publishing one NuGet package per app but we’re not publishing one for every country anymore.
Base Application, Application and some of the test apps for the base app are the only exceptions to this. They’ll continue to be published in a country-specific NuGet, since they are different in every country. But generally, there will only be one NuGet package per app.
A part of this change was also to move the NuGet publishing to the same pipeline that publishes the bccontainerhelper artifacts. That means, from now on these NuGets should automatically be published when a new version of BC becomes available. That was not the case previously where the publishing was done ad-hoc. In this case the 26.5 NuGets were never released. I’ve kicked off a pipeline run to get those added to the feeds.
Where was this change announced? Unfortunately, I didn't hear about it.
There are few unresolved things>
- mixing old and new ways of naming in same feed breaks one fundamental rule we had - that there is only one Package ID with specific Application ID in the name (except the when runtime/symbol tag is used). Now we have two>
It means querying the feed for package with the specific AppId is now returning two names and we need to add additional logic to check which one to use 2. Having two packages with distinct versions we cannot use generic dependency tree resolution, because if I have e.g. app depending on BCv26 but I am looking for dependencies versions compatible with BCv27, I cannot do that because for each version the package is named differently. Thus e.g. using Paket CLI will fail on this. We need to generate older versions for new name or new versions for old name.
It was not and that is my mistake. Here's what we'll do:
I'll trigger a publish of the remaining NuGet packages so we can get those pushed out as well, and we'll continue to publish these for v27.0 - v27.5. In the meantime, I'll work on an official announcement I'll share on Yammer.
The background for this change was really two things:
- We wanted to improve how we publish the NuGet packages so partners can rely on the NuGet packages being there when we ship a new major or minor.
- We wanted to reduce the amount of NuGet packages we produce. Up until now we've produced 20+ different NuGet packages containing the System Application. We'd like to get to a place where we can publish the System Application in one NuGet package only. The current design won't really scale with the number of apps we produce within the BC team.
But of course, those things have to happen the right way with an official announcement some time in advance. Since that didn't happen, we'll continue to push out NuGet packages the same way we used to for a little while longer. Sorry for the confusion!
Still, the double packages with same AppId in one feed could be a problem in some cases. To solve this, you will need to unlist and remove the new one. Will you do that?
@aholstrup1 I adopted the BCC NuGet class in my project (almost without change except a few improvements for better handling of app preview packages) and this is failing now for v27 builds, so I assume that the AL-Go is also not ready for this change when some of the packages are non-localized (from what I see it still relies on dependencies defined in the package that are no longer correct as non-localized apps target W1 base app that is not correct for projects that needs localized base app)
I've added two new feeds (MSAppsV2 and MSSymbolsV2) where I'll direct the "new" NuGet packages towards while I work through these issues. They're empty right now but I expect them to be populated over the next couple of days. That way we'll keep the same old way of generating NuGet packages in the MSApps and MSSymbols feeds until we've worked through the issues.
@kine can you elaborate a bit on why it's an issue that we have multiple NuGets with the same AppId in the feed? That's essentially what we've had all along isn't it?
Yes and no.
By general, the rule was to have only one package for given AppId and Tag (runtime/symbol) combination (symbols and runtime packages are expected to be in separate feed). Exception was Application with localization tags, but this has no AppID in the name of the package (decided by "MS", same for System) - because it really exists in different "flavors" where the .app file for different localizations are different, even when the app has same AppID. AppID is in the name of the package to be able to find the package only based on the AppId. But this is more complex problem which was not well thought out, because in case of renaming the app or publisher, we will have same problem as now when we changed the localization tagging rule.
It means it is problem of "renaming" the package at the end and how the tools and dependencies will handle this.
In general
- in case of direct dependency you need to decide which name is the correct one - the old one or the new one? What if there will be more than 2 (apps renamed multiple times etc.)? It will need to be "intelligent" enough to decide correctly.
- in case of indirect dependencies (I am depending on A and it depends on B) - I cannot "fix" this dependency to use "new/old" versions which are included under the new/old package name - it means there will be some period of time where I will be forced to somehow fix the things...
It is not about "it is not possible to solve", but about "how much it will cost everyone" and "are we prepared yet?".
In case of rename of the app or publisher, it is mostly connected with some processes you will do regardless the NuGet packages - like changing the direct dependencies in the app.json of my apps, it means there will be new version of the app which will start using new packages with new versions.
In case of this "technical rename", there is nothing I need to change in the app.json, there will be no new versions of my apps, but publishing of my app will break with new versions of MS apps available only with new package names.
May be it will be good to look at this problem in same way as on any other obsoleting in BC. We are obsoleting old naming and moving to new naming. Let "mark" the old naming as "obsolete" and keep both for some "period" (best will be 2 years) to support both. During this period, partners will publish new versions of their apps and they will start moving to newer naming when upgrading to newer BC versions. But during this transition, both must be available in separate feeds to not break existing processes until they are prepared to transit.
May be I am biased, I see the NuGet packages for BC as my child (but I do not want to say that I come with the idea!) and I will be eager to hear more views from others on this...