I've searched all over SO and Google but have not been able to clear my confusion about this. It seems like a very basic question but am just not clear about this.
It is advised everywhere that you should have debug="false" on your production websites because this can have a significant performance impact as debug symbols are loaded when the site is compiled. Agreed - and that is what I have on the production site.
Our website (not a web application) is a .Net 4.0 website that I pre-compile on VS 2012 (and previously on VS 2010) using the 'Publish Website' command. The site is pre-compiled to be "UI updateable".
My question is: If I pre-compile my site, then how does it matter what the production debug mode is set to? I assume debug symbols are not loaded and code optimization is already done in the pre-compiled DLLs. To test this, I've tried switching the debug mode before pre-compilation and it has no effect whatsoever on the size of the DLLs in the bin folder.
This post here: Publish in debug mode but compiler removes code inside #if debug seems to indicate the the debug mode has an effect on publishing the site as the author wants debug info in the DLLs.
Am I missing something?
Let me take a stab on your question, hoping i got you correctly.
Starting from Visual Studio 2010, a new concept called Config. Transforms. Those are files that help you customize the web.config files during deployment package generation which is triggered during 'Publish'
Those transforms are tied to the build configurations. So you will have one for debug called web.debug.config, and so on.
When you click publish or generate your package by any means, VS checks the current configuration, debug for example, to generate the right web.config.
Related
I noticed one weird thing today, and I'll appreciate your input on this.
I was assigned to work on a VB.NET project. I took the project files from the server locally.
I opened Visual Studio and then did open project, the project loaded in the solution and I did build, I got errors, pls check screenshot:
http://gyazo.com/3fe2ea4d5ff8fd073355d43160861e70.png?1348166929
2nd try, I opened Visual Studio and instead open project, I did open website, I selected the folder where the files are located and then open website. I build the solution, it says build succeded and the website runs fine in the browser.
Now I want to know why that's happening, why when I am trying to open as a project I am getting errors, and when I am opening as a website, website starts ok.
Thanks in advance, Laziale
In VS, Projects and Websites are different - a Project is a collection of files managed by a *.proj file (e.g. *.csproj, *.vcproj, *.vbproj), whereas a Website is just a filesystem folder without much in the way of project management metadata.
The second main difference is that Websites have a different Build process - unless you explicitly opt-in to pre-compilation the project is not compiled at design-time, instead everything is compiled by the webserver at runtime, which means you need to distribute all of your source code.
It also means that compile-time errors are harder to detect. You will get the same errors in a Website as in a Project, it just means you need to perform a live website action that uses the same error-prone *.vb files, and you'll get a lovely YSoD error then (rather than in the IDE before you publish it).
"Websites" were introduced in VS2005 as an "easier" alternative to VS2003's ASP.NET Web Applications, but there was a lot of backlash from developers - I wouldn't be surprised if they removed it from a future VS release.
I want to include configuration for the Application Warmup module for IIS 7.5 in my application's web.config file ( an <httpWarmup> element inside <system.webServer>)
This works fine when the module is installed, but if I want to deploy the application to a server without the module installed (e.g. IIS Express) I get
HTTP Error 500.19 - Internal Server
Error
The requested page cannot be
accessed because the related
configuration data for the page is
invalid.
Can this be done? Is there a setting to make IIS ignore extra elements in <system.webServer> that it doesn't recognise?
Thanks
If you're using Visual Studio 2010 then you can use the web.config transformation feature. Using transformations you can, in combination with the website 'Publish' tool, transform your web.config and add/remove settings depending on whether you're doing a debug or release build.
For more information see:
Web.config Transformation Syntax for Web Application Project Deployment
How to: Transform Web.config When Deploying a Web Application Project
Scott Hanselman has a great demo of this feature:
Web Deployment Made Awesome: If You're Using XCopy, You're Doing It Wrong
This works with ASP.NET 2.0 and 4.0.
If you're still using Visual Studio 2008 then it's still possible to achieve this.
First off is to use a brute force approach and maintain multiple web.config files. When you build the project in VS you use a pre-built event swap in the correct web.config file. I've used this technique before but Scott Hanselman (as always) has a nice worked example:
Managing Multiple Configuration File Environments with Pre-Build Events
If you're using MSBuild directly then you could use a build task to modify the web.config files. There's an extension library available from the MSBuild Community Tasks Project which provides additional extensions to MSBuild to make these tasks easier. The XmlMassUpdate task is probably the task you'd want to use. I'll be honest and admit that I'm only scratching the surface of MSBuild at the moment and haven't actually tried this, but (and I don't mean this in a LMGTFY way) googling XmlMassUpdate returns a rich seam of useful looking hits.
We all know that we should only be publishing our ASP.NET Web Applications with release build type, so why do I not get a warning when I trigger the "Publish" command in Visual Studio 2008, for a project configured to build in debug mode?
Sure, there might be cases where I need to publish a debug build to a development or test environment, but answering yes in a confirmation dialog would be acceptable in these cases. Is there an option that I have overlooked, forcing Visual Studio to warn me every time I try to publish a debug build?
Yes, we could just ban using the "Publish" command and use a more solid build management tool, but this involves a change of process and might not be an option in this particular case.
Typically things like this are handled in an automated build tool. Quite frankly, I publish to a dev site by orders of magnitude more often than I do to production.
For that reason alone having an extra dialog box in the process would be a bit maddening.
Further, even without a build system in place, most people have different config files for the different environments and for the most part handle it with a web.config setting.
I use Publish to build and publish my development sites to the dev servers all the time, a question about this would just be irritating in my opinion.
I think the issue here is one of your personal process rather than the tool. Production releases should be far less frequent and would require you to change the location the site is being published to, if you remember to change that then it's not too much to also expect that you are publishing the correct build type.
You can set deployment retail="true" in your production server machine.config to stop worrying about it
<configuration>
<system.web>
<deployment retail="true"/>
</system.web>
</configuration>
Tip from Scott Guthrie's article Don’t run production ASP.NET Applications with debug=”true” enabled
When I use Build->Publish Web Site in Visual Studio 2008, most of the time it compiles the site, and then simply asks me "All files in the target folder will be deleted. Continue?" (or something to that effect). On occasion, however, when publishing a project in Visual Studio, I would get a dialog box that would give me the choice of replacing the folder's contents completely, or simply replacing changed files with newer version.
I much prefer to publish without completely obliterating the folder, because the deployed application creates user files and cache files as it's been used that I don't want to take extra steps to preserve. However, I'm not sure why Visual Studio doesn't always give me this option. Is this a setting somewhere I can change? Is it tied to the version of .NET I'm using?
Any insight is appreciated!
Edit - Followup on 2009-01-20
I still haven't figured this out, but here's some more information.
Here's what the publish function looks like for one ASP.NET project on my Win XP desktop:
And here's what it looks like for a different project on my Vista laptop:
Notice the radio buttons in the second screenshot that allow me to choose to either delete the contents of the folder prior to publishing, or merely to overwrite matching files. I'd like to have these options for every project.
Both computers are running Visual Studio 2008 Professional (version 9.0.30729.1 SP, according to Help->About). The exact same version. And I doubt the OS difference is causing this functionality change. It's got to be a setting somewhere, right? Does anyone know?
John is right, the only difference is one of your projects is a Web Site Project and the other is a Web Application project. You will not see the "convert to web application" option unless you are in a Web Application project. I know... it is very misleading. The reason behind this stems from the the way you convert to a web application project. If you plan on converting it(which can be a real pain in arse, depending on how it is set up) then you need to be aware of a few differences:
In a Web Application project everything is pre-compiled all the codebehind pages will be compiled into a .dll ---- In a Web Site Project nothing in the project is pre-compiled, the compiler will compile everything to ensure it is valid but none of the compiled pages are uploaded. When a user first attempts to access the site each page is compiled into its own dll. This means in a Web Site Project you are able to upload a single codebehind file.
Namespaces - In a Web Application project namespaces are created by default in a Web Site Project they are not. So you may have to spend some time adding them if you plan on converting them.
Project files - you will notice that A Website Project does not have a "cproj" file a Web Application project does.
I have converted a few of these project I find they go fairly smooth as long as there is not a lot of code in the "app_code" folder. You can give it a try and see how easy it is, if it looks like it is going to be a pain, I would suggest FileZilla just FTP it and save yourself some headache.
Good Luck
That dialog is different for Web site projects and Web application projects. In my MVC projects (Web application projects), I see the additional options. In my regular ol' web site projects, I see the first dialog posted.
Not sure if this option will be suitable for you but you could use the copy website function from the solution explorer. Click on the "Copy Website" icon at the top of the solution explorer.
I think the real answer to your question is that you should put your user files and cache files somewhere else.
When publishing a web site Visual Studio is designed to make sure that the target folder contains your web site files, and absolutely nothing else.
Apparently this feature is coming in VS2010 - that's what Vishal Joshi announced at TechEd EMEA in session "PDC307: Microsoft Visual Studio 10: Web Development Futures"
The site has been updated from the site in the updated layer.
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.