I have an ASP.NET website which I publish to a local folder / file share. I currently use Visual Studio 2022 Community edition (free) with the C# language.
On previous versions of Visual Studio (specifically 2017), when publishing single pages/files, the compiler would recompile the .cs files and the changes would be reflected after refreshing the page.
When I publish a single page with VS 2022, only the .ASPX files are updated, the code-behind (page.aspx.cs) files are never updated unless I clean the solution, rebuild and publish the project.dll file manually.
How do I configure VS 2022 Community to allow the re-compilation of .cs files when publishing?
Is this something that is included in the licensed version?
I have checked all the settings related to publishing, tried combinations of settings and done extensive research
There is no change as to how this works when using community edition. How this works will depend on if you using a asp.net web site "application". In that case, you open the project file (file->open project). When you publish such an application, then you have to do a full re-publish. The reason of course is that all code behind pages are stripped out and removed at publish time.
Then all of the code is compiled into (often) just one .dll, or a few and they are pushed out to the bin folder.
When using a asp.net "application", then a single page publish does not really make much sense. You can only publish WHEN no code behind changes have been made. If any code behind is changed, then such a publish of one page will not work, since no re-compile will occur on the server, but MUCH worse, is no code behind file will exist on the server, and worse is that the WHOLE site in most cases will require a full re-compile, since all of the .dll's and code resolving requires a full build, and there is NOT ANY source code having been published to the web site. So, the project can't be re-compile EVEN if IIS attempted as such.
If you are using a asp.net "web site". That means from vs you go file->open web site. In this case, it really doesn’t matter much, since BOTH the aspx page and the code behind page (.cs or .vb) are pushed up to the web site, and IIS does the compile based on the time/date stamp of the files in question.
So, with a web site? Then yes, a single page publish should work. I don't use that development and deployment model, but you may well have to select BOTH the aspx page and the code behind page - since both would need to be sent to the server.
From what I can tell, there has been ZERO changes in how this works, and this was the same in VS 2010 from 13 years ago, or now to the latest version of VS - including that of community edition which DOES NOT work any different in this regard.
So, publishing of a single page? You can just even copy the 2 files to the web site, or right click, and choose the publish option. All it going to do is copy the 2 files (aspx and code behind file) to the server. At that point, IIS takes over and NO re-compile of the WHOLE site takes place, but the ONE given page (along with code behind) should re-compile automatic on first use.
So, as long as both aspx + code behind file is placed on the server, then it should re-compile "on demand".
You also find that no "designers" files will exist, since build time resoling of your code and even resolving of dependencies does not really exist with a "web site"
Of course, choosing an "application" is far better from a developer point of view, since then you can have a project file, and even include additional projects (and set the build order). So, only an "application" allows multiple projects. And you have far better compile time checking of your references when using an application. You also find this setup works better with git-hub and with multiple developers.
And above also means that you can delete + 100% clean out the bin folder, since your referenced project .dlls are NOT to be placed in the bin folder. Of course, at build time, then all your .dll's and the one application .dll are created in the bin folder like any other application in .net.
Of course, while this "application" development model is FAR better, and you have FAR better resolving of your. dll’s?
The one big huge downside is that if you change ONE LINE of code behind, then a full re-publish of the WHOLE site is required, and thus a full re-compile, and a full re-build is required, even with just one tiny line of code behind having been changed. So, you lose out in ease of publishing, but win huge and wing big time with a far better development environment from a developer's point of view.
However, it certainly possible that somehow or somewhere along the way, you started opening an "application" as a web site, and that would result in a rather large mess, since now you trying to edit and develop on a "web site" as a "web site application" when you have no such setup. And of course, the reverse is also true! You don't want to start working on an "application" by opening it as a "web site", as that also creates a mess of galactic proportions.