I'm developing on a site with a few hundred user controls. When debugging the web app (pressing F5 in Visual Studio 2008), it takes quite some time to compile it and start Cassini. I've noticed that every user control is compiled to a separate dll in temporary asp.net-files and it takes quite a lot of time.
Is it possible to speed up this process, possibly by compiling to just one dll, and still be able to debug the web application?
This is from the article:
http://weblogs.asp.net/scottgu/archive/2006/09/22/Tip_2F00_Trick_3A00_-Optimizing-ASP.NET-2.0-Web-Project-Build-Performance-with-VS-2005.aspx
Enable the on-demand compilation option for your web-site projects. To enable this, right-click on your web-site project and pull up the project properties page. Click the "Build" tab on the left to pull up its build settings. Within the "Build" tab settings page change the F5 Start Action from "Build Web Site" to either the "Build Page" or "No Build" option. Then make sure to uncheck the "Build Web site as part of solution" checkbox:
Have you considered moving to a web application project? That will compile all of your code into one dll, but this could be a big change. I would try changing the start options first.
A few tips in here, which helped (batch="false" in web.config and moving the temp-files to a ram-disk):
http://blog.lavablast.com/post/2010/12/01/Slash-your-ASPNET-compileload-time.aspx
Also, consider building in parallel:
http://www.hanselman.com/blog/HackParallelMSBuildsFromWithinTheVisualStudioIDE.aspx
Related
Is there a way to precompile the ASP.NET MVC views on an Azure Web App (specifically when published via Release Management on VSTS)?
Once each view has been hit once, the page subsequently renders very quickly. But that first delay can be a doozy for users and there's no way to script touching each page.
I'm not sure if I need to change something in the build/release processes on VSTS (I am using the Visual Studio Build build step and the Azure Web App release task) or if I need to run something on the Azure Web App instance after it is released (or something else altogether).
It seems like finding some way to call aspnet_compiler after publish might be what I need (and I have seen that in reference to Web Roles on Cloud Services) but I can't get that to work.
Calling
%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler -v "/" -p "d:\home\site\wwwroot"
via the Console in the Azure Portal executes just fine (and finds errors if there are any) but doesn't have any impact on startup time - hitting a view the first time still takes a long time.
So maybe that isn't the right direction.
I've looked at RazorGenerator (including the .MSBuild nuget package) and I couldn't quite get it to work, but really I was hesitant to make so many changes to the projects just to get precompilation on release.
Also note that I am currently using TFVC, not Git, in VSTS, so the Kudu/Git integration (that does seem to trigger the precompilation according to some articles) isn't available to me as far as I can tell.
Other ideas?
You can add "/p:PrecompileBeforePublish=true" argument in "Visual Studio Build" step:
Then the task will call aspnet_compiler during the build process and generate a precompiled output for deployment.
In visual studio 2013+, choose Build->Profiles. Select the profile, then choose "Settings". Underneath "Configuration", expand "File Publish Options", and then check the "Precompile during publishing" option.
I want to build my solution, and then open a browser and test it, without pressing F5. Should be simple, I am sure I have done this before many times but in other VS versions.
I just cant figure it out :)
I have tried different settings on IIS and in the project settings for my app.
From VS, I use IISExpress and the project url is
http://localhost:1234/
I use asp.net mvc 5 with VS2013
I want to be able to close the VS instance and still run the app
For MVC applications. You typically need to do two steps.
Open the Project Properties. Select "Web". Select the "Specific Page" setting and leave it blank. Make sure no other settings have values either. This will force IIS Express to launch the app, but then the routing in MVC will take over.
Press CTRL+F5 to "Launch without Debugging". This launches the app without the debugger attached.
From there you can rebuild your application, but not have to press CTRL+F5 every time. IIS will detect the changes and refresh the ASP.Net worker process as needed.
I'm searching for a free ASP.NET profiler, and I stumbled upon EQATEC Profiler for .NET, but I can't find any instructions on how to profile ASP.NET projects with it. Please post step-by-step instructions or a link with sufficient info.
I'm using Visual Studio 2008 Professional and .NET 3.5.
It looks like they have changed their user interface since Pavel's instructions were posted. Here are the instructions I wrote up for my team. They replace steps 4-8 in Pavel's post.
To profile an ASP.NET application using EQATEC, just select the application’s bin folder in the App Path setting.
Then, click the Build button at the bottom of the form.
Then, load your app and go to the page you want to profile. Go to the Run tab and click the Reset Counters button.
Then, do the action that you want to profile. When it’s done, click the Take Snapshot button.
When that is done, a snapshot report will appear in the bottom list. You can double-click on it to view it.
This should work for ASP.NET web projects:
Compile your project.
Start web application. You can right-click on some .aspx file in Visual Studio and select "View in Browser". (If you start your application later you risk overwriting profiled DLL.)
Start EQATEC Profiler.
On the Build tab browse to bin folder of your project.
Click “App options” button
Set output folder to $(AppDir) only.
Uncheck “Ordinary app”.
Click Build button.
Switch to your favourite browser. Navigate to the page you want to profile. You should get "Profiled app started" entry in Run tab in EQATEC Profiler.
Click "Take snapshot" button. A new entry should appear in "View snapshot reports" list. Select it and click View button.
Edit: Updated instructions according to comment.
From the EQATEC forums:
ASP.NET?
tracing asp.net web application
Profiling web application
You may need to get a compiled version of your site (is there a dll for the site in the bin folder or just the dependencies?).
The easiest way to do this is to publish it. (Just right hand click the site in Visual Studio). Then Pavel's answer will work just fine.
Why are the code-behind pages for an ASP.NET web application locked at run time? I have older projects (probably defined as "web sites" instead of "web apps") where I can edit the code behind, refresh the browser, and see my changes. With the web app, I have to continually close and reopen the browser if I want to see my changes live. Is there a setting or something I'm missing to allow me to edit at run time, and without restarting the debugging session?
You can enable Edit and Continue in the project properties. Right click the project in the solution explorer, select the Web tab and check Enable Edit and Continue.
Now you can edit your sources, but you have to pause the debugger to do so.
When using IIS as your development server, Edit and continue is not currently available for Visual Studio for ASP.NET.
See this blog entry, however, that shows it is possible for the Visual Studio 2005 Web Application Project Project type. It requires using the Visual Studio Development Server (Cassini) during development instead of your local IIS (see the properties box on the project).
No, in web applications, the codebehinds are pre-compiled into dlls, so any change in the dlls will recycle the App pool, and stop your debugging session,
If you press ctrl-F5 instead of just F5 to start (or host you site in IIS), you start without the debugger, and don't need to restart the browser all the time...
Unless you really really need to debug a problem you can't figure out, You should start the web app without debugger, makes it snappier to start up. Every minute spent debugging is a minute not spent writing a unit test. IMHO you should write unit tests, they last longer.
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.