EPiServer CMS 11.18.0 delisted from Nuget feed

Hi Magnus, I think we might be a victim of this issue on at least one customer in production (yes, I have contacted the support).

In our case it is about the UnifiedSearchHit and the OriginalObjectType property being null on the instance - is this related to this issue?

Thanks, I've included that in our "test matrix" for this. It seems related, the issue is in the runtime type identifier of the proxied content type classes.

In our case the workaround was to force the Castle proxies back to use with this appSettings configuration (gotten from Episerver support). And if someone missed the 11.18.0 release contained the new custom IL generated proxies to replace the Castle proxies: https://world.episerver.com/documentation/Release-Notes/ReleaseNote/?releaseNoteId=CMS-15856

<add key="episerver:setoption:EPiServer.Core.ContentOptions.ProxyType,EPiServer" value="Castle" />

And after that is applied in the target environment a full re-indexing for Find needs to be done.

After that everything was working as before. Imagine a big thumb here :D

Thanks for confirming, we're on the same track.

If we have deployed to 11.18 can we downgrade to 11.17, and then when 11.18.1 is available we'll update to this version?

I got same question from our colleagues, but thanks for letting us know here.

@Loa Skogø Lind 11.18.1 should hit the Nuget feed tomorrow so I suggest you use that instead of trying to go back to 11.17. Note that it you have had 11.18.0 running you should reindex the site after 11.18.1 deploy to ensure index consistency.

Thanks Magnus. We need 11.8.1 in order to make our CI/CD work because all builds are failed due to 11.18.0 is no longer existed. Downgrade is not a good option :).

@Magnus, can you comment here or should we talk to support? In our case we use the 11.18.0 version but have reverted to Castle proxies with appSettings and re-indexed Find, so everything works. So when 11.18.1 gets released, should we remove the forcing of Castle proxies and re-index Find?

@Antti Alasvuo 11.18.1 will ignore that option and always use Castle proxies. So if you have already reindexed with Castle proxies, you don't need to reindex again after update.

@Magnus, thanks for the information.

I guess this means the custom IL generated proxies feature is removed for now then?

@Magnus, should we reindex after update from 11.18.0 to 11.18.1?

@Justin, I think Magnus already answered that:

• if you are running 11.18.0 without adding the appSettings key to use Castle proxies and re-index, then when you update to 11.18.1 you should re-index because you might have inconsisten data in Find index
• if you are runnung 11.18.0 with the appSettings to force Castle proxies and re-index, then when upgrading to 11.18.1 you don't need to re-index and you should remove the added appSetting

@Antti, Thanks

@Antti correct on reindexing strategy.

About the optimized proxies we're taking a step back and looking at how we can make that work without issues with Find and preferrably without requiring reindexing. And if it requires changes in the Find client how do we make sure releases/dependencies of the Find client supports this so no one ends up with a broken combo of versions. We would like to release it as an auto-enabled feature because of the performance gains, but the fallback would be to have it as an opt-in feature.

I am trying to upgrade to 11.18.1, but the nuget-package-installer is complaining about the 11.18.0 is missing.

How do I move on? Do I the 11.18.0 package locally?

Thanks.

To answer my own question we got the *.nupkg files from Episerver Support so the nuget package installer did not complain about the missing version.

@Loa thanks for the input. I'm reluctant to put the 11.18.0 package back on the feed even if it is delisted. We don't want anyone accidently installing it.

Is deprecating the package an option? Or is that only a nuget.org thing? https://docs.microsoft.com/en-us/nuget/nuget-org/deprecate-packages

If you could deprecate instead of delist, then we'd still be able to build sites where we can tolerate this issue. Because of the delisting, a significant of our build pipelines were effectively down (including sites that don't use Find or are just integration builds where we could easily tolerate the issue), and the only option to get builds working again was to downgrade or wait for the update.

@Bob Davidson I think deprecating means the whole package, not a specific version. A de-listed package version shouldn't be a problem to download with a specific version, e.g. like the tool does when you restore packages. But it won't appear in version lists and might not be used when resolving dependencies from other packages. I'm not sure here and that is the reason I'm reluctant to even put the package back as de-listed, because there are packages that depend on the 11.18.0 version or higher but I'm not if any of the different dependency resolution packages in Nuget could mean it actually picks the broken package if it is even available on the feed.

The updated version is already there so you don't need to downgrade anything. As mentioned earlier in the comments you could get issues updating if you are currently on the removed version, because nuget apparently might reach out to get the currently installed package as well as the new one when updating. This could depend on whether you have the package in cache or not.

Mangus, the Nuget documentation makes it look like you can choose to deprecate specific versions or "all versions" of a package, at least for packages on nuget.org.

We're in the process of upgrading our effected projects now, so we're reaching a resolution. I understand your hesitency to put the package back up, and frankly I don't know the correct answer here. My understanding of "delisting" is that the package basically wouldn't show up in search, but would be generally available for restore, but all our CI builds with this dependency were failing to restore this package. I just wanted to suggest deprecation as a possibility for any similar issues in the future, should they arise. Thanks.

@Bob Davidson thanks for the feedback, I'll look into the deprecation feature to know how we can use it in the future. Meanwhile I have done some testing and it does seem that when the package is de-listed it is not used in dependency resolution. So we should be able to put it back as de-listed to help with upgrades. I need to discuss this with other people tomorrow though.

Meanwhile, if anyone has problems upgrading from 11.18.0 because the package is not there anymore, you can reach out to support like was mentioned in an earlier comment, or perhaps easier: Just manually edit your package.config / package references to point to 11.18.1 for the CMS packages instead of 11.18.0. You also need to manually update binding redirects or reinstall the package once you have got it to restore the 11.18.1 version.

After careful deliberation we decided to not put 11.18.0 back on the feed, to keep that as an obstacle to anyone who might already have it referenced and plan to go to production without knowing this. Sorry about that for those of you who have found your way here and are now trying to update and run into problems. For you I have uploaded the files here, see link in the post itself. Just put those files in a folder and reference that folder as a package source and you should be able to restore and update fine.

Since a couple of weeks back we have CMS 11.9.0 published which should be foolproof, see updated text at the bottom of the blog post.

I was getting an "Entry Point Was Not Found" exception on a handful of my templates with Find 13.2.8 and adding the key to my web config to go back to Castle solved them.  I did report the bug in the forums, and while going back to Castle is a good bandaid solution to keep my code base up-to-date, I don't know how future-proof this is.  Hopefully there will be some documentation added to explain some atrubutes I may need to add in order to use the new optimized context proxies.   

@Valina Eckley thanks for reporting this. Your report on the forums was picked up yesterday by our support engineers and forwarded to Software Engineering last night and we now have a repro and a fix that I hope will make it into the next release.

We don't intend to move away from the Castle proxies completely. They are still needed for certain parts of the platform. The new "Optimized" proxy is a performance optimization.

Thanks for the update.