Hi there, I've recently upgraded an Umbraco Cloud project from v12 to v13 (using the guide here: https://docs.umbraco.com/umbraco-cloud/product-upgrades/major-upgrades) The guide does not mention that (as far as I can see) an Umbraco 12 project has both

Program.cs

and

Startup.cs

, whereas v13 only has a

Program.cs

... now, everytime I find a "How to do [XYZ] in v13" article, it references methods in

Program.cs

that don't exist in my project's file... are the upgrade docs I followed missing a step to upgrade those files, or is that not expected?

I think it's skipped because the previous approach with both file still works just as well. However I do see your problem with the

Program.cs

being different. My approach would be to backup the current

Startup.cs

and

Program.cs

- and delete both of them from your project. Then look at the default v12 version of

Startup.cs

https://github.com/umbraco/Umbraco-CMS/blob/v12/dev/src/Umbraco.Web.UI/Startup.cs Things kinda migrated from

Startup.cs

to

Program.cs

so the v13 default

Program.cs

looks similar https://github.com/umbraco/Umbraco-CMS/blob/v13/dev/src/Umbraco.Web.UI/Program.cs I'd put that default

Program.cs

in the place where your previous

Program.cs

was. Finally, look at your backed-up

Startup.cs

and see if you made any customizations, they should slot into the new

Program.cs

in similar areas (hard to give general advise, so hopefully you didn't customize too much, but most of it should be doable). Now that I'm writing this, I also realize how difficult it would be to document it 😅

Thanks @Sebastiaan 🙌 — Let's see how far my patience takes me with this 😸

Happy to help if you attach your current files

This video is quite handy -

The only thing I would like to add to this is If you find any customizations, move them into composers instead. (we are slowly updating the docs to no longer add things to program.cs) Using the service provider in the composer interface or the IUmbracoPipelineFilter, you should be able to anything you can in startup. Doing this future proofs your solutions for future changes to program.cs It also allows you to more easily copy functionality from project to another (as it should be self contained within its classes and composers)

I do like doing this as well, but it is sometimes incredibly painful to figure out how to do things in a composer. Chriztian's happy place is XSLT and not C# 🙂

Happy to try and make the docs better around composers regarding specific feature implementations if I get told which ones are lacking 😉

As pointed out to me recently: all the examples in microsoft documentation customize

Program.cs

so that's how most people are going to be doing it anyway. There were other (more hypothetical) objections mentioned as well, but I can't find the thread now. I think it was around slight extra overhead and/or ordering possibly being a problem, can't remember exactly.

Thanks everyone 🙌 - specific to docs and blogposts, the two issues I usually run into are missing info about where some piece of configuration goes in

appsettings.json

, or having to figure out which

using

statements I need for the code to work (I know everyone else use VS Code or Visual Studio, which probably figures this out automatically).

What are you using? If not VS or VSCode or something else that handles usings (e.g., Rider).

My particular issue with doing it in program.cs vs composers is the unknown side effects by the umbracobuilder having already registered things, and needing to inject in a certain order (eg addCors I know we have extension points now for pre/post routing middleware as well as pre/post pipeline). If it's the case that program.cs is the way to do it.. then perhaps Umbraco should drop the umbracobuilder and register it's dependencies natively in program.cs? 😉 But then you have the issue of how do you update program.cs going forwards by umbraco updates.. as seen here (although startup to program in this case) it falls back to a manual approach maybe via the specific version updates? I do always compare startup|program.cs between updates (remembering back to when namespaces and method names changed during the inital core implementation) On the topic of adCors for instance it's always difficult to know when extension endpoints happened.. spent a while looking at the postRouting only to find it only arrived in a particular version of v12 I think... I know should be updating to the latest versions, but the umbraco rapid cadence makes it economically unviable for some clients. 😦

@Chriztian Steinmeier you might benefit from https://marketplace.visualstudio.com/items?itemName=Fudge.auto-using But I agree with you, all documentation should mention the required

using

statements, it's all to easy for people to get confused without them, especially if they're not proficient in dotnet and/or haven't found out how visual studio can help them yet.

I use a native macOS editor called Nova - so only does syntax highlighting (which is, frankly, all I need for my everyday frontend stuff).

So your 12-to-13 upgrade was dry-coded? And you don't see the results until pushed2cloud? That sounds unergonomic. 🙂

I am able to run the site locally 😀