We recently converted a website made with .Net WebForms from a Web Site project, to a Web Application Project.
This is all well and good, except it's now a pain because to change any of our code-behind files we have to rebuild the whole site, whereas before all we had to do was save the code-behind file.
This means changing pages in logged in areas requires not only rebuilding the whole Web Application, but then logging in again for a user.
Is there a way to remove the precompile option while running locally so we can debug as we used to with a Web Site project?
I have tried removing the <compilers> section from the web.config, and also removed the <compilation> too, but neither seem to have made a difference.
EDIT:
I realise now I wasn't very clear. I'm talking about debugging the site locally, not when publishing.
No.
Web Application projects load from a DLL; they have no option to compile source at runtime.
You should specify a fixed validation & decryption keys in Web.config so that users don't need to log in again after deploying (more detail).
Related
I understand that references are stored in the project (vbproj) file for ASP.NET web applications and the Web.Config (http://msdn.microsoft.com/en-us/library/37e2zyhb%28v=vs.71%29.aspx) for websites.
I have recently converted a website into a web application. I notice now that the web application will publish (using the Publish option) even if the version information is incorrect in the Web.Config, then when accessing the web application through a browser I get an error.
I was unable to Publish a website if the version of an assembly in the Web.Config was incorrect.
I read that web applications are precompiled (before publish) whereas websites are compiled the first time the website is accessed through a browser.
Therefore, I believe what I have said should be the other way around i.e. I should be able to publish websites with an incorrect version in the Web.Config (because they are not compiled) and I should not be able to publish a web application.
What am I missing?
After some further research; I have discovered that ASP.NET web applications are built using MSBuild and ASP.NET websites are built using ASPnet_Compiler.
ASPnet_Compiler looks in the Web.Config for referenced assemblies (add assembly tag) at build time, whereas MSBuild looks in the project file (vbproj) at build time.
Web applications are deployed without the vbproj. I believe the project file is used for linking. Therefore at runtime a web application uses the information in the Web.Config to identify assemblies to look for in the local bin folder and then the GAC (for aspx pages only)i.e. namesapces still have to be manually imported into the code behind partial classes.
If anyone has any comments or better answer then please post.
I want to update a class library (a single DLL file) in a production web application. This web app is pre-compiled (published). I read an answer on StackOverflow (sorry, can't seem to find it anymore because the Search function does not work very well), that led me to believe that I could just paste the new DLL in the bin folder and it would be picked up without problems (this would cause the WP to recycle, which is fine with me because we do not use InProc session state).
However, when I tried this, my site blows up and gives a FileLoadException saying that the assembly manifest definition does not match the assembly reference. What in the world is this?! Updating the DLL in Visual Studio and re-deploying the entire site works just fine, but it is a huge pain in the rear. What is the point of having a separate DLL if you have to re-deploy the entire site to implement any changes?
Here's the question: How can I update a DLL on a production web site without breaking the app and without re-deploying all of the files?
The thing to remember is that there are web sites and web applications as far as Visual Studio and ASPNET is considered.
Web Sites typically have all of the aspx and vb files published to the live server and ASPNET Worker Process recompiles the app every time before presentation.
On the other end is the web application, where all of your code behind files get compiled down to a single DLL file and you simply deploy your aspx pages and you bin folder with the DLL file to production.
There is also a "hybrid" known as "Precompiled Web Sites" (see the link for the official MSDN overview) where you don't have the single DLL layout of a web application, but all the compile work of the website is done for you. There are several "modes" to this depending on your needs.
It seems to me that your error is caused because your site is set up as a web site with some kind of precompilation in place. Using the pre-compiled model is a little more "strict" in that is assumes certain files/signatures are in place. Having an updated version of the DLL file causes a break since the precompilation wants a name and a version of the file.
If possible, your best bet would be to convert to a web application, since you can add the additional DLLs into production without a problem. Otherwise, take a look at this matrix to see what form of precompilation you need for your application.
Look at this SO post, might be what you are referring to. The located assembly's manifest definition does not match the assembly reference
Have a look at your reference. Does it say "specific version = true" ? Set it to false, republish your app (you have to do it once, because now your app is still looking for an assembly with a specific manifest) and try it again.
I've been trying to migrate a fairly large web application from IIS6 to IIS7 the past few days, but every time it seems like we're about done, IIS7 fails to load aspx pages.
The application is a .net 3.5 webapp that makes heavy use of reflection and web services. We use 2 main components (each with their own web site in IIS7 although they share an application pool): the web UI (aspx pages), and the webAPI (asmx pages).
The webAPI portion runs perfectly (as far as we can tell; there are a few things we can't test from the browser), and the web UI pages load static HTM pages just fine. The problem is that once we attempt to view an aspx page (any aspx page), the whole thing just comes to a halt; no error is logged in the event viewer until a few minutes later when we get an IIS 5010 warning (worker process ignoring ping).
We've attempted to migrate the app in two different ways:
Manually: we moved all the necessary files and set up the virtual directories then converted them to Web Sites. Result: the worker process took up 100% of a single core and spun forever (until terminated manually)
Automatically: Utilizing the MSDeploy application from www.iis.net we archived the entire IIS6 web server and unpacked it into a blank IIS7 install. We had to turn off Forms Auth to get rid of a 401.2 error, but after that the result here was that the webAPI component still works just fine, but instead of the web UI worker process taking up 100% of a single core, it grew to about a third of the required memory then hung out doing nothing.
Either way, what happened from the user's point of view was the same.
Unfortunately, we can't even attach a debugger to the worker process because it doesn't seem to be loading managed code.
Details:
.net framework: v3.5
CLR version: v2.0
IIS Authorization mode: Anonymous
OS arch: x64
App arch: x86
Happens with both classic and integrated pipelines
Notes:
New web projects seem to work just fine in IIS7 and, of course, xml web services are also fine
temporary DLLs are created and stored in the temporary ASP.net DLLs folder, even though the worker process never seems to contain managed code.
New pages added to the web UI project also show the same behavior (Didn't hurt to try)
Updates:
We've narrowed down the problem to a single assembly. It's a wrapper for a third party web control. I'm looking into replacing it, we'll see if it fixes the problem.
http://support.softartisans.com/kbview.aspx?ID=1318
Turns out it was an issue with the vendor control. Wish their solution actually worked though...
Try to re-register ASP.NET:
http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
The typical command line syntax would be to command line to the ASP.NET 2.0 version of your framework and type:
aspnet_regiis -i
Are you using the "Classic" Pipeline Mode for your Application Pool. The "Integrated" one is the default in IIS7 and it introduced changes in terms of configuration. (One example is HttpHandlers that need a different configuration in web.config).
The "Classic" one mimics the IIS6 application pool, and should work with the same configuration as for IIS6.
If you prefer to use the Integrated Pipeline, there are some tools that will automatically try to convert you configuration files.
Scott Hanselman covers some of these tools in his blog post.
We have a web application project (not a web site), until the day we have added batch="false" to web.config web development server was compiling all the web application instead of the page that was requested.
<compilation debug="true" batch="false">
<assemblies>
...
</assemblies>
</compilation>
This make us faster. But I don't know what changed (I have inspected both foo.cproj and web.config from repository, comparing older versions but find nothing can cause this slowness).
I looked at %temp%/Temporary ASP.NET Files; after I compile my web app (not recompile, shift + f6), then I request a page and I see that web server deletes all of already compiled files from %temp%/Temporary ASP.NET Files and recreates. I don't know if this is normal but it seemed to me a full recompilation of all web app, which is very slow. (I looked via process explorer to wevdev.wevserver.exe it calls csc.exe several times)
How can I can make compilation faster? Thanks...
There is an option for ASP.NET Development Server named 'Enable Edit and Continue' that is available with the 32-bit version of NET CLR. Turn that off in Visual Studio.
Also, try changing the build for 'Any CPU' in a build for 'x86'. That should make compilation faster.
I believe this is a part of using the Web Application Project. Any time you build your application, the entire site is recompiled. You should see that unlike a 'Web Site', the web application all compiles down to a single dll (plus references).
Another thing you have to watch out for is any time you delete a file/folder under your root web app folder it will also force a recompile, which can be a real pain in the butt for temporary files.
On the plus side once you get over the first compile, there will be no additional waiting for compile times on unvisited pages.
I'm comparing it Java where you can start your application server in debug mode, then attach your IDE to the server. And you can change your code "on the fly" without restarting the server. As long as your changes don't affect any method signatures or fields you can just hit recompile for a class and the application server (servlet container) will reload the class.
I suppose this is impossible in ASP.NET since all classes are packed into assemblies and you cannot unload/reload assemblies, can you ?
So when you have an .aspx page and an assembly deployed to GAC and your codebehind changes you have to redeploy the assembly and reset IIS. I'm talking about Sharepoint applications in particular and I'm not sure whether you have to do iisreset for private assemblies but I guess you have too.
So the best way to debug aspx pages with code behind I guess would be to get rid of the codebehind for the time of active debugging and move into the page, then when it is more or less working move it back to codebehind. (This would be applicable only for application pages in Sharepoint, site pages don't allow inline code )
How do you approach debugging of your ASP.NET applications to make it less time consuming?
From Matt Smiths blog on how to get F5 debugging with sharepoint. A very cool trick.
Create a web application project in Visual Studio (File -> New -> Project -> ASP.Net Web Application, not File -> New -> Web Site).
Move the .csproj and .csproj.user files, along with the Properties folder, into C:\inetpub\wwwroot\wss\virtualdirectories\, where is the name or number of the web application corresponding to the SharePoint site you'd like to debug on.
Attach the project to an existing solution (e.g. STSDEV project).
Set as startup project (right-click project name, "Set as Startup Project").
Access project properties (right-click project name, "Properties") and click
Under the "Servers" setting, click "Use IIS web server", then enter the URL to the SharePoint web application you want to debug on, e.g. http://mymachine:99.
Yes private assemblies DO NOT require reset of the IIS. So you should just to xcopy new version to the application's Bin directory and refresh the page (e.g. by VS post build event as I did).
But there are some trade offs. You should decrease trust level in application web.config file:
<system.web>
...
<trust level="WSS_Medium" originUrl="" />
...
</system.web>
By the way. I do not suggest to deploy like this. It's just workaround for comfort write-test-debug cycle length.
If you are using the GAC, you can at least do iisapp.vbs /a "App Pool Name" /r instead of iisreset (it's quicker to recycle a single app pool than to restart IIS).
First, develop on a computer running SharePoint. Preferably, this means running Windows Server 2003 on Virtual PC or VMWare. This will let you deploy and debug SharePoint code directly, rather than having to copy files between servers and use the remote debugger.
Use a VS add-in to simplify the process of deployment and debugging. I've been using WSPBuilder but I think there are others out there. WSPBuilder has commands to deploy solutions, package them as WSPs, and attach your debugger to the local IIS process. It won't allow you to add/remove assemblies on the fly, but you can set breakpoints and run code through the Immediate window in VS.
Depending on how your production server is configured, it's usually a good idea to develop on a server with full/trust security settings, including disallowing code blocks in ASPX files. This makes debugging a little more difficult, but it reduces the number of nasty surprises you'll have when your code is finally deployed to production.
And you can change your code "on the fly" without restarting the server
You can accomplish this with ASP.net if you make a Web Site project (as opposed to a Web Application Project). Using a Web Site project, you can post changes to code-behinds without having to refresh anything on the server, and the server does the compile work for you on all code changes. See here for more info on this.
This should also solve your difficulties with deploying the assembly to the GAC. As the server handles all compilations for Web Site projects, you wont have to redeploy any assemblies when changing files.
Use an automated testing framework (NUnit) to write integration tests. This won't work for everything, but of course, it depends on what you're testing.
If you also have TestDriven.NET installed, you can run individual tests with the debugger. This has been helpful.
WSPBuilder Extensions has a "deploy to GAC" shortcut, unfortunately it never works for me. But it's a really quick way to code->compile->test.
If you're not using WSPBuilder Extensions, you can instead open a command prompt and run
gacutil /u yourassemblynamegoeshere
gacutil /i yourdllgoeshere.dll
If you do this often, you can put it in a post-build event or in a batch file. Also, I'm unclear whether the gacutil /u (to remove the DLL first) is necessary.
What it seems like you're trying to do is tell Sharepoint "When I start debugging in Visual Studio, use the version of the DLL that was compiled in the project's /bin/debug directory instead of the version of the DLL that is registered in the GAC." I haven't solved that problem, but here is how I debug Sharepoint.
A developer machine is Win2008, IIS 7, MOSS 2007, VisStudio 2008, and WSP Builder installed. Inside VS2008, a button is added to attach to w3p.exe process, Andrew's HOWTO attach to w3p
The solution file has two projects:
* First project is the .WSP that deploys all the app pages, including the DLL. Use WSPBuilder menu items for handling the .WSP creation and deployment.
* Second project is for the DLL behind the pages.
If you want the DLL to be copied to the GAC regularly, add a post-build event to the DLL's project that copies from /bin/Debug to the GAC. But, these days, I find I have just been recompiling the solution and then deploying the .WSP using the menu items, and then starting up the debugger using the button. It takes me an F-key and 3 clicks and about a minute for most of my projects, but I suppose it could be quicker.