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.
Related
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
Our application registers events OnInit. When developers create a new aspx file from the visual studio template, it has AutoEventWireup="true". This leads to event handlers being registered twice and run twice.
Is there an easy way to cause the compile, build or other post build step to fail when the directives are set "wrong".
I'm using Visual Studio 2010 and TeamCity. I'm open to running any technology as a postbuild step.
You could precompile your site. Precompiling involves compiling the aspx and ascx files aswell as the .cs. It will make your site faster and it ensures things hook up a bit better, the downside is you cant change the aspx or ascx after you have compiled them.
http://www.dotnetperls.com/precompiled
This SO page describes a couple of ways of doing it
Compile Views in ASP.NET MVC
You could try integrating StyleCop with TeamCity, and create a custom StyleCop rule that checks for this. Not sure how difficult it would be, but it's what comes to mind. See this question about using StyleCop with TeamCity.
Also, as suggested by Erix, update your templates to prevent this from being the default behavior.
How useful is it to use Aspnet_compiler.exe instead of conventional Publish via Visual Studio? And what about resource (resx) files?
Precompilation, as opposed to simple xcopy gives you two main advantages:
The filesystem will not have all the code in .aspx files and all the code behind is compiled into an assembly.
There is no ASP.NET compilation delay the first time you visit a page after the server starts up.
Having said that, my precompilation knowledge is a bit rusty these days, last time I touched it was a while back.
By pre compiling the site your server won't have to compile the site on the first visit. You have probably noticed that the first time you view an asp.net page there is a noticeable delay.
In addition you don't have to ship all your files since the code is already compiled. This can be useful if you don't trust whoever is hosting your pages.
Visual Studio's "Publish" feature is actually just a nice frontend to aspnet_compiler.exe. Publish has the advantage of being very easy to execute, where aspnet_compiler.exe requires some tweaking to get the results you're after.
Is there a tool or some general approach to packaging all the files of an ASP.NET application into binary form to prevent modification once its deployed? I am thinking there would be a set of signed binaries and a config file for settings that we allow the customer to modify. Has anyone attempted this, is it even possible?
I would pay a reasonable amount for a slick commercial product that did this with minimal hassle.
UPDATE
Sorry, from the answers I can see that I wasn't clear. I meant literally packaging ALL files, not just the code files. This means aspx, scripts, images etc. I'm not trying to prevent reverse engineering... this is a supportability issue, i.e. to avoid dealing with problems brought about by customer messing with the files.
If you made a web application project than you can compile your code into a single dll file. You can find it in the bin folder.
Just use aspnet_compiler.exe to precomple everything and then use aspnet_merge.exe to roll up all of the compiled assemblies into a single assembly. You can use an obfuscation tool like DotFuscator if you want to make it more difficult to reverse-engineer. Visual Studio pro and up include a "lite" edition of Dotfuscator that you can use for this.
Your codebehind files will be compiled in a single dll as ZippyV already mentioned. The aspx files will get deployed normally on the webserver.
But still, your dll files can be disassembled quite easily. So to be sure you have to use an obfuscator.
If you mean ALL files including the aspx you could also consider ngen. It precompiles everything into a dll so you can't even get at the aspx pages.
Although, ngen was designed to get rid of the JIT compiling feature of the framework and is definitely not a generally recommended approach but it may work in your case well.
From VS2008 select the menu option "Tools" and then "Dotfuscator Community Edition". You will have a "Learn More" link after it starts up.
I also sign mine using SN.exe to make it have a strong name. Given all this, I think it is complicated enough to figure out a system if you are given the source code and help.... so I don't worry about it anymore.
maybe Dotfuscator your customer won't be able to modify it nor reverse-engineer it :)
It's really annoying that visual studio hides typos in aspx pages (not the code behind).
If the compiler would compile them, I would get a compile error.
Compile the pages at compile time. See Mike Hadlow's post here:
http://mikehadlow.blogspot.com/2008/05/compiling-aspx-templates-using.html
Go to your project properties. Go to the Build Events tab.
In the Post-build event command line: text area, write this (for .NET 4.0):
%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_compiler.exe -v / -p "$(SolutionDir)$(ProjectName)"
Resharper will catch errors in code ofASPX pages, all without compiling. works well imo, and better than later compiling.
EDIT: Resharper also has a Solution wide error checker. 'Resharper->Windows->Errors in solution'. It will analyze your entire solution and give a consolidated list of everything it finds, INCLUDING aspx files.
It is my belief you should always compile ASP.NET applications. There are a few instances where my clients requested otherwise. In Visual Studio, when you choose to publish your website, there is an option to have it compiled. Here is Microsoft's MSDN article which offers their information on compiling sites.
http://msdn.microsoft.com/en-us/library/ms178466.aspx
HTML issues and such will show up as "warnings" and not errors. So, you'll have to check the logs.
There is the possibility to precompile the whole web: usually the pages only get compiled, if they are used.
To precompile the web, please refer to MSDN