Just read about the possibility to use codefile=somefile.aspx.cs instead of codebehind=somefile.aspx.cs in web application projects (described here). Obviously this causes the file the compile only when loading the page, it's not precompiled anymore (right?).
Are there any negative or unexpected side-effects by using codefile instead of codebehind in a web application project?
I think you could run into problems for supportability if your site isn't all one or the other. (CodeFile or CodeBehind)
i.e. If you're trying to figure out a problem on your production site that your error handling tells you is within a certain file or namespace, you'll have to stop to examine every file and control that you are supporting before troubleshooting to see if the page is running as part of the compiled assembly or running from the codebehind on the site.
You could also run into conflicting or missing namespaces if you try to have a mixed environment.
Pros as I see it for CodeFile:
Your production source code can sit on your production website. If the code is all compiled in a DLL in your bin directory, there is no absolute guarantee that the code you have on your development environment or source control is what's out there. (Sure it SHOULD be, but if everything was always as it should be, many of us wouldn't have jobs fixing other people's code!)
For updates, you only have to push out single files, not an entire assembly.
You would be able to have developments in progress on other pages that you don't need to back out before recompiling and publishing to production.
Cons:
Since you're not pushing out a compiled assembly, you may have errors within individual files, that won't necessarily be caught unless someone visits each specific page or if you are sure to compile before deploying.
You may have conflicting namespaces in codefiles that may never be caught and could cause confusion or errors.
Performance issues for dynamic compilation
Related
Our development team has used aspnet_compiler as part of our build process for years to verify our website build. I have noticed that when the process encounters a precompile error, it immediately shuts down. Sometimes, if you fix the issue and restart, it will fail again with another unrelated error that actually existed the first time. I am just wondering if there is a way for it to not "die" and continue the precompile and then list ALL errors that it finds so we don't have to do the iterative process of fixing the errors one at a time.
I have looked at this documentation: https://learn.microsoft.com/en-us/visualstudio/msbuild/aspnetcompiler-task?view=vs-2019 but nothing there seems like it supplies what I am looking for.
do you mean that VS shutdowns, or the external command line build process shuts down? One real problem area is the .net folder called app_code. While you can do a build->compile?
You note that code in that folder does NOT get compiled when you do this. It is only compiled by the build process. Even during debugging, you note that compile errors are not seen (or caught) unless you run (try) the site. As a result? I don't use that folder anymore. The 2nd huge problem is royslen editor code. I have started using that ability's for strings to span multiple lines in - really nice for in-line sql.
However, I find then if you let the web site build, it does NOT support + see and allow such Rosylen formatted code. (so upon run of the site, I get errors). (this might well be due to the web site running IIS 2016 - too old for that new code formatting support (at least in vb.net it is).
So, all I did was create my OWN folder for code and NOT use the .net one ().
Note that you create the folder, but remember for EACH code module, or class you drop into that folder? You have to individual set each to be compiled. (it is the default), but be careful if you import code via add. So you see (and want) to use this option:
So, I of course don't want the source included - and I don't require that since this is a web applicaiton vs a web site.
Thus, I don't get/see/have any runtime compile of my code by the web site compiler process - it all done during the build and even debug process in VS.
And then their is the build for a web site publish. Thus during a deploy build (and publish), I don't get any surprises either.
In other words, the GREAT advantange of a web site applcation is you don't let the web site comile code for you.
You do have to mark the code module as per above.
As a result, this folder behaves like any web form with code behind. The standard debug and build process during development will thus compile all my code - and catach errors.
If you use the built in (and special) folder app_code, then such code only compiles WHEN you run the site, and worse it is the web site that does this compile - NOT VS.
(but of course you publish build process ALSO does this compile!!!).
I need (want) a regular build + compile during the development process to catch and compile all that code (else debugging, and worse compiling means you only can find out issues at web site run time - and that's way too late for my tastes).
So, I don't bother with app_code anymore at all. Now I am lucky, since I am creating (using) a web site application, as opposed to a asp.net web site. (and yes, there is a massive difference).
Asp.net web site = each page and code behind will compile on demand. This choice is perferred for two big reasons:
First, you can update one web page (and code)- deploy that one web page + code. The web server will figure this out - and re-compile that one page on demand. This makes updates and maintains of the site OH SO VERY much easier.
And it also means in most cases that the whole site can be published to a sub-site folder on the hosted web server. And in fact most really cheap low cost web site hosting MUST use this option (web site applications in most cases can't be published to those lower cost .net hosting sites). (thus use web sites, not web site applications).
However, if you lucky, and you have FULL use of IIS and a server dedicated to JUST running your web site? Well, then you are MUCH MUCH better off to go with a aps.net web site application. And this also means you can say setup custom logon providers, and also configure things like re-direction or things like a custom web handier. In effect, this choice means that you as a developer not only have full use of the base starting page, but can directly change/configure the web server to your liking. This includes the base web config.
This choice is often not avaible on lower cost hosting plans. it requires that you have full IIS services, and IIS services is running your whole site, and the base starting page is your site. (you can publish to root on web hosting, but you still using THEIR EXISTING copy of IIS services, and you can't control things like creating a custom authneticaion (logon) provider. And you also can't create re-directs (custom one).
However, in both cases/choices app_code folder behaves like a compile on demand folder. Thus bugs and issues in that folder will thus not be found until you run the web site, or do a full deploy that then does the full site build. and as noted, you can't use Rosylen eiditor souce code features, since the web compiler might be a few verisons old. You be running the SAME .net version, but the older compiler does not support source code formatting with the new Rosylen editor features.
Since a web site application will compile everything (whole site) in your application down to a single .dll (and of course referenced libraries), then then you don't have on-demand occurring by the web site compiler (after you deploy). Of course the publish wizard does have options to combine all those .dll's into one - not a big deal either way.
So, the one exception is app_code. So I just stopped using it, and I see little reason to use that special .net folder anyway.
So, it was never clear if VS is shutting down, or your build process is seeing errors not being caught during the regular development cycle with VS - if this is your issue, then the above approach should solve the problem for you.
My searching skills seem to be failing me on this one. It is a simple question;
In ASP.NET is it possible to store class files in a folder not under app_code?
What I am trying to accomplish is create class files which when added (or modified) to the web site will not cause the web site to restart. Anything under App_code or in the bin folder causes a restart. We are not using .NET for the presentation layer.
My reason is simple, we make changes somewhat regularly, and I do not want to wait until a specific time to add/change a feature. These are 24 hour websites and there is no great time to restart them.
Edit:
I am using FluorineFX to access the middle tier. I created a folder called "ProdCode" from the root of the application. When I try to access the NameSpace ProdeCode, class Employee_Calendar method getEvents. I get the error "Failed to locate the requested type ProdCode.Employee_Calendar"
Well, the goal of a non-restart is huge different, and HUGE separate from that of being able to place code modules, or class modules in some other folder.
When you build the project, most of the modules (and class ones) are crunched down to a single .dll anyway.
So, while you are free to add new folders and inside of those folders add new code/class modules? That may not well eliminate the need for the site to re-load, or in fact the site to re-compile the code again.
All of the app_code, and any other code module will crank out and result in a single .dll file. So, I don't see how you going to gain, or win anything new here.
What you could perhaps do is build some classes outside of the project, compile them, and then set a reference to the external code (and class) modules in the other project. That would suggest a external .dll. This would work during debugging, but an "il-merge" usealy occurs when publishing as non debug, and thus the gazillion .dll's are merged into one.
So, separate out code - great idea.
Adding code to additional folders - sure - no problem (do right click on the given class, or code module and make SURE the build action is compile - this is a default for app code - for other folders I can't remember. You need to check this.
so, up to this point? Hey, all great.
But, to save site re-compile time? No, this where train is flying off a big broken bridge, and the whole she-bang is crashing up in a HUGE ball of flames.
You might be able to same some time during debugging, but those included module are pulled into the "main" .dll (same name as your applcation). Go check the "bin" folder now - you not see the app_code .dll's but only one main .dll with the name of your project.
Such re-compile time is useally rather fast for the site to re-load. I you are just changing markup, then fine. But the idea that you want to include compiled code, and attempting to avoid a re-load? No I would not consider this - even if you could! I mean, how many times have you seen code fail or NOT take even after a publish and FORGETTING to re-start the web server? Those .dll's are often loaded into memory, locked and 100+ more issues exist. I many a time lost half a day because my .dll's did not take (due to me not re-starting the web server). there is pain and then there is this kind of "pain" in which parts of your application don't load. I just can't imagine the risk vs rewards in trying to save some time??? - I must be missing something here?
I have faced a lot of issues with Publishing like when you need to make small changes on the code, sometimes the generated DLL file (the dll file for example of default.aspx.CS when published) cannot be recognized by IIS saying the codebehind is wrong or something. Sorry for not remembering the exact error message. I am hoping you know what I mean at this point.
Therefore, I usually do a simple Copy Paste operation instead of Publishing.
Could you tell me what am I missing by NOT using the Publish method? How is Publishing better? Or which one do you prefer, why?
Basically its a pros and cons situation.
Thankyou
Well, it depends on what you mean by "copy":
With Publishing you have options to pre-compile all or part of your application. You can publish to a local folder in your file system (instead of your target/host) and then copy the updated file(s) (only). If you are making "code behind" (c#/vb code) changes, this means you'll likely only need to "copy"/overwrite dlls. Goes without saying that if you've made "content" changes (html/razor/script/etc) changes, then you'd need to copy/overwrite those as well.
If you're new to deployment, you may find yourself simply copying/overwriting "everything" which is the safest way to go. Once you get more experience, you'll "recognize" which assets you only need to update (one or a few dlls and or content code, instead of "everything"). There's no magic to this, usually, its a matter of just looking at the timestamp of the dll/file after you've published (locally) or rebuild your web application.
I'd recommend doing a local publish so you can see what is actually needed on your server. The files published to your local file system/folder is what needs to be on your host/server. Doing so will visualize and remove whatever "mystery" there is to Publishing:
you'll see what is actually needed (on your server) vs. what's not
you'll see the file timesstamps which will help you recognize what files were actually changed vs those that weren't (and therefore don't need to be updated).
once you get the hang of it, you will not need to "copy"/ftp "everything" and just update files that were actually modified (only).
So "copy" can mean the above, or if you are saying you will simply copy all of your development code (raw (vb/cs)html/cs/vb) to your host, then that means your site will be dynamically compiled as each resource is needed/requested (nothing is pre-compiled). Also "easy" but you do lose pre-compilation which means there is a delay when each of your web pages are requested/needed (ASP.net needs to dynamically compile). Additionally, you are also exposing your source code on the server. It may not mean much depending on your situation, but it is one more thing to consider.
Here's more info on pre-compilation and options.
Assuming we consider an aspx page and its aspx.cs code behind file, there are three alternative ways of deploying your site:
You can copy both to iis. The aspx will be compiled to .cs upon the first request and then both .cses will be compiled to a temp .dll
You can "publish" to iis, this will compile the code behind class to .dll but will copy the aspx untouched. The aspx will be translated to .cs and then to .dll upon the first request
You can "publish" the site and then manually precompile it with the aspnet_compiler. Publishing will compile the code behind to .dll as previously but then precompilation will clear out your .aspx files by removing their content and moving the compiled code to yet another .dll.
All three models have their pros and cons.
First one is the easiest to update incrementally but in the same time is the most open to unwanted modifications.
Second is also easy, can be invoked from vs, it closes the possibility of some unwanted modifications at the server but .aspxses still need time to compile upon the first request
Third takes the time and some manual actions but prevents any changes and also speeds up the warm up of the site as the compilation of assets is not necessary. It is great for shared environments.
I have an ASP.NET website where the pages call a few components in DLLs. I need to change the signature of a method in the component, and short of doing a text search, don't know if this will break any pages or not. IMO, this is the weakness of web programming -- you don't get the benefit of a compiler telling you about syntax errors.
But it doesn't need to be so. Does anyone know if there is a way to run a spider over a website watching for compile errors, or perhaps some tool that would compile all the .aspx files in a folder structure looking for compile errors?
This is merely for syntax checking -- not to actually pre-compile the website.
EDIT It looks like aspnet_compiler is being recommended. I don't use Visual Studio projects for the website -- it's grown over time with my own templating system (back before Master Pages were available). So something that would run aspnet_compiler over all the files in a folder might work...
There is a flag that you can put on your project that tells it to compile all the aspx files when the project is compiled. It adds time to your build, but it can sometimes be worthwhile. See http://mikehadlow.blogspot.com/2008/05/compiling-aspx-templates-using.html
Also, Resharper is really good at finding references to methods, even in aspx files. So if you use Resharper to rename a method, as long as your solution includes the web project, it'll find and rename that method in the aspx files, too.
This is one of the many reasons we use development tools like Visual Studio in the first place. The single easiest way to do what you're asking is to develop with an IDE that DOES compile and check for errors, even ifyou choose to publish teh un-compiled code.
Since Microsoft offers Visual Web Developer for free, there's really no reason to NOT use it.
The compiler will automatically catch and any report any errors in your .cs source or code-behind pages. Your assumption that the compiler won't catch syntax errors (such as getting the arguments in the wrong order when calling a method, etc) is incorrect - that's one of the primary benefits of using a compiled language. If you're experiencing something that contradicts this, please post some code.
If you're concerned about errors in the ASPX files or in your views (if using MVC), you can have the IDE precompile ASPX files, as well.
See this article for more information.
I turn this off most of the time since it slows down compilation, but I use it before deploying a site as an extra verification step.
For example how this site is organized?
What i do not understand is what they upload to the Microsoft server?
I have created, with Visual studio, a very small web-page and i have to upload the whole site, even after the smallest change...
The usual approach is to replace everything with xcopy or the publish function in visual-studio, and in some cases replacing everything is the only approach - for example if you're using the web-application project model everything gets packaged into a single assembly and there you go - even to apply a small change you'll have to re-deploy the whole thing.
An alternative to this could be the Website model in visual studio, using which you should be able to deploy single code files on your server and they should be picked-up if you re-start the website from the IIS management tool. This model - in fact - works in a different way compared to the web-application project model. It's just a bunch of code files that will be dynamically compiled by the ASP.NET runtime.
Even if possible though - I wouldn't suggest the approach of deploying single files - as this is easily error prone (you deploy the code-behind and could easily forget to deploy the aspx counterpart, or similar). Unless you're delpoying Gigs of stuff over slow-networks, redeploying the whole thing is always the safest bet.
Have a look at this and this interesting links to find out more about website and web-application project models in visual studio.
It really depends a lot on how you're building your app.
If you're in VS and you're doing an ASP.Net site, then you can either do it as a Website Project, or as a Web Application project.
in the former case, your files will remain as aspx and .aspx.cs files and you xcopy (or FTP) whichever files change. if you want logic that's outside the scope of a single page, you'll either create a separate class library project or else use the App_code directory.
In the latter case, you'll compile all the logic into one or more .dll files that get copied to your site's /bin directory, and any number of aspx files that can either stay as such or be embedded (recommend leaving them as aspx files). Again, if an aspx file changes, you just movethe one that changed, if anything in the dll changes, you replace a whole dll.
All that said, a huge chunk of what's on the site you posted is probably being pulled out of the database. Most sites now dont' have content on pages, they just have organizational (view) logic on paes, and have other classes which fetch the actual content out of a database to serve up. This allows greater reuse and means that the 4,000 pages (number chosen at random) on MSDN don't have to be each coded individually as an HTML page.
After Googling i think, the check-box Use fixed naming and single page assemblies in the publish Website form of the Visual studio, is the right choice.
Although it might slow things down...