Good day
I moved to another company from a previous one, they task me to modify a existing system with a horrific code, but with patience and dedication, I managed to update the system, but I was shocked that they told me to put the source code on the system and it will be the one that the app in IIS will read. It will read the debug folder of the project. On my previous employer what we do is to publish the file, and that be one to read, but on my current employer,they put the whole source code on the web server.
Is this okay? Or am I right it's a bad practice, well other frameworks put the whole file on the server, so it should be good? Is it?
Thanks and regards
CodePudding user response：
It would be a history lesson.
More than two decades when Microsoft designed ASP.NET 1.0, the developers were using classic ASP which is simply Visual Basic code running on IIS. Thus, ASP.NET 1.0 has the mode of "ASP.NET Web Site" (used by your current employer) that you put source code on IIS and compile on the fly to mimic classic ASP.
It was after a few more years that Microsoft realized how bad that mode is, and introduced "ASP.NET Web Application" mode (used by your previous employer).
Microsoft has urged "ASP.NET Web Site" projects to be migrated to "ASP.NET Web Application" (or simply ASP.NET Core) for more than a decade, but unless IIS stops supporting those projects, many will not migrate at all.
"Is it okay" is impossible to be answered. Your current employer seems to enjoy that very well.
Reference
CodePudding user response：
As pointed out, this was a common set.
And after all, why bother to do some whole big publish when you JUST need to modify say a bit of markup in a web page.
So, for those who have the web server "on site", then often they would point VS to the site, and open it directly.
So, to manage/use/work with such a project? You don't use from vs file->open project, but in fact use file->open web site. At this point, it is assumed you browse directly to the folder that holds the web site - often the live web site.
There are several significant issues to be aware of.
the app in IIS will read. It will read the debug folder of the project.
That is a not a correct assumption, or even correct view. There is no such thing as a "debug" folder. Then again, be it a console app, desktop, or whatever? Sure, when you COMPILE code, it goes to the bin/debug or bin/release folder.
But, you failing to grasp that by using the "web site" option, VS does NOT do the code compile!!! (IIS does!!!). While testing in vs, then vs will do the compile, but if you are modifying the web site directly, then all you have to do is open a web page, and when you hit ctrl-s, you are done - it is now live. And this ALSO applies to code behind.
So, you can open up say the code behind page. Modify one line of code and hit ctrl-s - you are done!!!
So, yes, as you note, a lot of web site(s) were managed this way.
So, the upside is no real deployment is required. And for a larger site, this actually can be a benefit.
However, the downsides are significant, and you VERY much need to be aware of these issues.
First up, careful if you adopt Rosyln extensions. That means your testing/debug/playing/developing code using and allowing VS to compile the code.
however, when you deploy (or edit "live"), then VS is NOT doing the code compile anymore. And this ALSO means then that the web site has both aspx pages, and ALSO the source code pages MUST ALSO exist!!! But often the web site and version of IIS will for example not know about Rosyln extensions etc., so you HAVE to be VERY careful, since it not VS that compiles the code, it is IIS that does this!!
In fact EVEN with a web site application, the "app_code" can and will be compiled by IIS. (I had simple code break when IIS re-compiles that code - it was not aware of say free form text strings that Rosylin allows). So, for a web site application, I actually create my own folder called MyCode and for each code module/class inside, then I right click and choose "compile" for the build options. That way IIS NEVER gets to compile my code!!!).
Now, of course the other option is what we call a "asp.net web application".
In that case, when you publish, then the code is compiled for you, the code behind pages is stripped out, and only the aspx pages remain (and are copied/deployed) to the web site. While this is more "pain" since even a tiny one-line change of code requires a WHOLE web site re-compile and re-deploy.
However, while there is this "increased" pain, there are also significant advantages.
You can have multiple projects in the one project.
you can add and reference other projects assemblies - not have to move/copy the assembles into the bin folder.
So, with better skills, then of course you often build code libraries and systems - systems that ALSO the web site requires. So, a asp.net "web site application" is a far better choice (compared to the "asp.net web site").
So, coming from a traditional software background, then hands down, I prefer the ability to have multiple projects in the one and same web project. And hands down I prefer the runtime compiling and management of external libraries of code and references being managed by the vs as opposed to "hoping" you setup and managed references correctly with a web site.
So, even those starting out say with PHP, or many other systems? Yes, they run a web server all the time, and then go edit the source files - and a simple "save" of the file you just edited means then a browser refresh, and you are done.
however, you lose a lot of control over referenced libraries, and KNOWING the build compile is the same one you be running on the web site after a publish.
And note that a web site publish in effect will be just the SAME copy of the existing web site and files - there not really a "compile" process for publishing, and hence no "debug" folder really exists. It also means that each page launched on the site can out of the blue cause code to compile.
(Whereas with a asp.net web site application, there is a small startup delay the first time - probably due to JIT's running, but other than that, each additional pages and parts of the web site will not then have significant delays. With a web site re-publish, then huge delays can occur (but then again, often you never really have to re-publish do you - you are editing the live files!!). But, if you are working on a test copy, then yes, you are going to re-publish everything (actually copy the files - since nothing more is required). And as such then the web server really will be slow to start up, and slow to open pages that have not yet triggered compile of the code-behind pages (and you get a gazillion little .dll's as a result).
So, the only real issue here?
MAKE SURE you open the web site using file->open web site as opposed to file->open project. In theory and practice, such "web sites" thus don't have a .sln and project file. (it really is just a folder of files). As noted, many love this setup, especially for larger sites, since then little changes here and there are very easy. However, from an overall software management point of view, using git and source code, and things like writing unit test code, shared libraries, using multiple projects in one vs project file? You give up most of this with the web site option. So, yes, that setup is quick and dirty, but it not all that great if you more formalized in your software development approach.
I prefer strong references, and strong typing during the development process. I also prefer having VS manage my references. So, these abilities are worth more than a simple ctrl-s to update some code. However, if some bug crops up, while it can often be fixed by a simple edit of some code file and ctrl-s, and you are done? it will be harder to track down and find that bug in the first place!!!
To be fair, once a code project is created, then changes and fixes are often rather small - and this again actually favors that simple edit and ctrl-s deployment model.
it can often be painful to have to do a full re-publish of a whole big web application for JUST one little, tiny change of code, or even markup. And in most cases, when I deploy, I stop the web server services, publish, and then re-start the IIS web services.
So, it can "often" be hard to make a case that this deployment model (well, it doesn't really have a deployment model!!!) is bad, since it oh so easy to update bits and parts of an existing running site.
However, in the long run, I really can't endorse this way of development. I MUCH prefer using a web application. It is more git friendly, it allows things like testing code (unit testing), far better use of external class and library code, and you have a MUCH better control of compile and build of your code. Letting IIS compile the code base has increased risk, since you can't be sure during development that your final code and project will run the same when you deploy. (or least be far surer!).