I recently revamped my companies website, creating a new asp.net Website Project (I believe).
In the past, before the new site was created, I was able to do single page updates/publishes to the site with out having to recompile the entire site. Now, in order to publish changes, I need to build the site and publish the site.dll file along with all the updated files in order for the site to reflect the changes.
The problem with this is that when I'm working on additions for the website that aren't ready for production, it includes this code and causes compilation errors if I do not comment it out before I publish.
I still have the old project/solution. I have compared the publish settings but as far as I can tell the only real differences between the two projects is the target Framework and the editor used for the project (old project was created in VS 2017, new site was created with VS 2022)
My company is currently looking into version control software which should help with this situation.
Is there a certain project type or project setting that will allow me to once again do single page publishes with out having to also publish the .dll file?
It is a challenge.
If you want the ability to publish out the one page (and code file), then you can't use a "web site application". But that choice ALSO then takes off the table the use of a project file.
When you create a asp.net webforms project, you have 2 choices.
Asp.net web site
Asp.net web site "application"
And the above means that when you create a "web site", then you do NOT have a project file. This setup allows you to publish/change ONE page, and you can then send that one page up to the web server. You also of course in such a case have to send both the .aspx page, and the code behind (source code) page to the server (that would be the .aspx.cs or .aspx.vb (if using vb.net).
So, this setup was in the old days often used, since it made deployment of one single page and code changes very easy. There was no need to re-publish and re-build the whole application.
However, there are also HUGE advantages to using an "application".
They are:
You get/have/enjoy use of a .sln project file.
And with a project file, then you can include multiple projects in your one project. Thus, you might have some set of class libraries that you created with all of your helper routines, or large amounts of your business logic. With a project file, then during build, then these "multiple" projects will build for you, and build with ONE build operation.
In addition, assembly references and "resolution" are far better with a project file (application choice). And this setup also means that you NEVER have to include the source code files when publishing. In effect, your developer computer does the compiling of the project, strips out the source code, and only .dll's and the .aspx pages are then published and placed on the server. So, from a developer who used to a "real" development environment in which you build + compile your code BEFORE publishing, then of course an "application" is the way to go.
Another great advantage is that your additional assemblies and referenced. dll’s are NOT placed in the bin folder during development. So, you can do a "clean" project and "all" of the bin folder is deleted. So, you have a clean build each time, and you can even open up the bin folder and "delete" all files (.dll's) in that bin folder.
Upon a re-build then all of your correct assemblies, referenced library .dll's, and even NuGet packages are copied over and into the bin folder for a final AND CORRECT build of the site.
So, your .dlls are "produced" at build time and THEN placed in the bin folder. You thus always have the correct .dlls and ONLY the final correct .dll's placed in the bin folder. With a web site, then boatload of "stuff" and "junk" piles up - including often .dll's you don't need nor want anymore.
Without a project file (web site choice), then references are not resolved by the project building process, but will be resolved by the web server and it’s compiling process. In other words, IIS the web server will be compiling your code and not you anymore! This can be VERY problematic when say using the newer Roslyn compiler extensions (which may well not be installed on your target server - or worse yet, you using some web hosting plan, and you can't install Roslyn compiler extensions).
So, the only real downside of the "application" choice is that you can't publish JUST ONE page. However, the list of advantages such as pre-building, removal of source code, allowing multiple projects into one project, and more still VERY much outweighs this lack of being able to update + publish one page and it's code. And as noted, no source code is placed on the server when using an "application".
So, that single page publish? Well, sure, kind of nice, and you simply copy the .aspx page, and the .aspx.cs page to the server - it will automatically detect you done that, and re-compile the code for the one page. However, this means that near each web page creates it's own .dll - you have 100's of them as a result.
So, what do to when you 3-5 days into new features, but then you find one bug or one page that needs fixing on the web site?
Well, hopefully you using SCC (source code control), and thus you can revert back to the current published version, create a branch, make your changes, and re-publish.
So, while many a sites in the past did use the "web site" option? And it's easy? Well, I find the lack of assembly resolution, and that of having to place NuGet package (.dlls) in the bin folder is a VERY messy affair, and you loose too many features without a project file, (such as being able to include other projects).
So, if you not using git-hub? Then at publish time, you have to ALSO make a whole copy of your project, and that would allow you to change the one page, and then do a re-publish. So yes, the one downside is that to update one little page and one little bit of markup? Yes, you have to do a 100% full re-publish.
So, in the past, you probably were using the asp.net "web site" choice, and thus you use file->open web site in place of file->open project from VS to work on that project.
I simply find it very difficult to work without having a project file, and value having FAR better increased support for referencing libraries and NuGet packages worth MORE then the ability to publish one page.
However, if you not using some kind of source control, then if you are 2-5 days into a bunch of changes, and THEN you need to fix one bit of code or change one page? Then you are in trouble, and of course that "one feature" that you don't have in an "application" will bite you.
You simply don't have a partial or single page publish option. But then again, you never had that ability with say any desktop project either, did you? So, for 30+ years, what did developers do when working on some big desktop project, and they need to fix a single form or some code?
Answer: they revert back to the current build, branch the build, make the changes, and THEN push out the changes they made to the master build.
Only you can decide the advantages of an "application", but having a proper project and correct build process for any application for me wins over loss of the single page publish ability.
So, one solution here is to adopt source code control. Another is to always make a copy of the whole project when you start some work that going to take more then 1 day of time.
Another idea? Well, I simply "hide" or "turn off" say the new tab or button, so then the new features can be easily turned off (hidden) should the need arise to re-publish the site to fix say a bug, or change some markup.
I should also point out that you do NOT open such "web site" projects by using a project file - you MUST use file->open web site, and browse to the folder.
As I stated, only you can decide the value of having a project file, or having the ability to publish and push out one page + the code file is a better choice for your needs.
And some caution is required here, since tools exist to "help" and convert a web site to an "application", but the reverse is not automated, and thus you have to manually change each page if you going to try and convert or "revert" your project choice back to a "web site".