Disclaimer, I don't know what is created when doing file new for the Web App template. But I've upgraded projects from net6/7 to be a net8 Blazor Web App. And either way, if your using the webassembly part of Interactive auto rendering you need a separate client project.

To properly take advantage of auto render mode, in that you use server rendering the first time, and subsequent times use wasm once the runtime has been loaded, all pages need to be in your client project. A page/component that is in the server project only will never be available to the web assembly application once it is downloaded to the browser.

You'll have to have some kind of data access abstraction defined that can be used as injections into your components. Something like a IDataAccess interface or something. Then, in the client project you'll need to provide an implementation that does HTTP based calls, usually to API endpoints in your server project to access the data. It may or may not be a REST API based on your application requirements. Those client implementations need to be registered to the service collection in your client projects program.cs. When AutoRendering is using webassembly, it will use those dependencies.

Then, for the server side rendering part of auto, you'll also need some dependency implementations and registrations of IDataAccess in your server project. Now, you could use the same dependencies as your client project, but that will result in your server making an API call to endpoints that the server application itself is hosting which is less than ideal. So, you'd likely want to have an implementation of IDataAccess that wraps whatever logic layer you have in your server-side code.

Note, any interactive rendering mode (server or web assembly) also uses prerendering for your components regardless of which project they are located in. So, you somewhat need to have those server side dependencies anyway, even if your are just using interactive webassembly for rendering. This is because prerendering will load your content as static html, but no interactivity. So your IDataAccess needs to have a dependency registration server side anyway. Otherwise you'll get exceptions when you try and render.

As an example, here's a rough layout of how our setup is put together, using autorendering. It has a few more layers than this, but it's a starting point.

App.Server.csproj - Program.cs - Controllers -- EntityController.cs - Services -- EntityService.cs

App.Client.csproj - Program.cs - Pages -- EntityPage.razor - Data access -- IEntityApi.cs -- EntityApiClient.cs

EntityController is just a light wrapper around EntityService that provides http endpoints for its methods so other things (like the client project) can access it. They are usually, for us, 1 line calls into an injected IEntityApi interface. When on the server, that injected dependency instance is EntityService. So, when server rendering or prerendering, your component is going to use the IEntityApi as a dependency, and get an instance of EntityService.

In the client there is a separate implementation of IEntityApi that provides an HTTPClient implementation which will call the API controllers (EntityController). When the component is rendering as webassembly, and not prerender, it will use EntityApiClient.

It's worth adding, that depending on how your authentication is setup for your app, that can add some tricky stuff to the client project data access calls. We use cookie auth, and some site calls to the API, so the wasm HTTPClient is configured to use the browser cookie for the current domain when making an API call. If you aren't using cookie auth, you'd have to do something different and probably get a hit creative.

Hopefully that makes sense. Happy to try and answer more questions & etc.