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.
Related
I have a working codebase of a web application written as ASP.net webform application, Visual Studio community edition. How do I start the application. Meaning how do I start the application / debug,
Community edition IDE expects something like a .sln file which I don't have, or its not present in the codebase.
I have been writing code for more than a decade, but I am new to ASP.net, require some help.
Normally (as you note), you find(have) a .sln file.
However, if you don't, then usually you have (will find) a .vbproj file for vb,
or a csproj file for c#.
When you open these "project files", then VS will create .sln file for you.
However, the 3rd possibility is this is not a asp web site application, but a asp.net web site (note HOW VERY close the term is I used:
Asp Web site = (no sln, and no project file)
Asp Web Site Application = (should have a .sln, but you have one if you open proj file).
So, if no .sln file, and no .vbproj/csproj file is found?
Then you have what is called a asp.net web site.
They are VERY close in terms of editing, writing code etc. However, a web site is NOT opened as a project (.sln/.proj) file, but you simple use this option:
In this case, then when you select above option, then you JUST browse to a folder, and you don't have a .sln/.proj file at all. You are in effect just opening a folder that has the web site inside.
I don't have a great/nice link that explains the difference between a asp.net web site vs a asp.net web application.
However, the major difference is:
The Asp.net web application
near ALWAYS expects that you have a dedicated server to publish to (so lower cost hosting will not work).
You have both control over the whole web site features - can write custom page handlers. You have more options for authentication. In effect, you can code and change "base" features of internet services. So, you have direct use of the web server features - and can over-ride behaviors.
Asp.net web site
This really is just a sub folder. So, for example, this option can be used to up-load your web site folder to a existing server. And you can modify one page (and code behind), and you really don't have to re-publish. This option of course OFTEN has to be used if you using some low cost web hosting. You can't publish a web app, since it would quite much over write the server features - including the base starting page.
With a web site app? The whole site is re-compiled, and the whole application is compiled down to ONE .dll. (much like a desktop application, of course additional .dll's and libraries can appear as separate .dll's). but, they are usually all merged into one .dll.
So, the existing of .sln, or .csproj/vbprjo files will quite much tell you which type of web site you have.
While a web site app requires a full re-publish of the whole site - even for one small code change - I still prefer that setup WHEN that option is avaible. This is due to having additional options, and control over session() events, and more.
However, as noted, in a lot of hosting environments, you only get a folder and some place to shove up your folders and web pages - and thus full web app publishing will not be a option for you.
#albert-d Fantastic answer!! it led to a lot of development,some how i figured out something.
cd theapp
dotnet new web # Create basic web soln/app
dotnet run
This sort of created default web app on the folder
info: Microsoft.Hosting.Lifetime[0]
Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[0]
Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
Content root path: /Users/raj/theapp/
On the browser it give nice output
But when I try to execute my old files present, like
http://localhost:5000/Default.aspx
Its not working.
Giving following error
Looks like I am losing a battle for want of nail. Could you pls clarify.
ASP.NET Web Forms apps have a large startup cost on the first request as they need to compile the views code (.ascx, .aspx, etc). We have to deploy these projects to several servers, which requires priming each of them so that the first users to hit certain areas of the site don't have a bad response time. Today this is a manual process, and we're making it automated by running aspnet_compiler.
Is is possible to run aspnet_compiler on the build server and deploy its output so that we do not have to run it on each web server we're deploying to?
Bonus Question: When we specify a target directory with the targetdir option in aspnet_compiler, how does IIS know where to look for the compiled files? i.e. Where is that information stored?
The project in question is a Web Application project (not a Web Site project).
There is an option in Visual Studio's Publish dialogue which may be what you want.
I've not used it to see if it actually has the effect you want, but there's several options in Configure for it. You may be able to do what you want with that.
(P.S.: This is an ASP.NET Web Forms Project as well, in VB.NET. Though the language is irrelevant.)
Also, according to this MSDN article you can add the -u and -v switches to the aspnet_compiler to get it to precompile the views for updating.
You may also want to look at this MSDN article as well, as it describes a scenario similar to yours. Especially the Compiling an Application for Deployment section, which states:
You compile an application for deployment (compilation to a target location) by specifying the targetDir parameter. The targetDir can be the final location for the Web application, or the compiled application can be further deployed.
Essentially, you might be able to run this command on your build server, and then distribute your binaries as needed.
I have an ASP.net that I built in VS2010 running in iis7 however when I go back into VS and make updates to the code behind file and re-publish the application still acts as it has before I made the changes. I have tried deleting and republishing all the files and restarting the app pool but it still doesn't affect how the application behaves.
project-->Property's--> Package / product web--> Items to deploy --> All files in this project folders
now publish your project.
your new files also added in publish folder. . .
DO NOT publish your vb and cs file on there server unless you feel like having your source code potentially exposed. There have been multiple vulnerabilities that have allowed code download.
Publish the application to a folder via the visual studio publish menu.
On the server, go into your temporary aspnet folder for example:
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
and find your app and delete it. If you cannot delete the files stop the worker process (w3wp.exe) or restart iis.
Republish and all should be good. If you are in doubt if that version is getting executed then add some logging in the new version or trace information.
There are two options for publishing an ASP.NET site to a server:
Copy the .aspx AND aspx.vb (or .aspx.cs) files to the server. The first user to hit the server causes compilation so it takes a little bit of extra time for them. Once that's done, subsequent hits should not be impacted.
Copy just the .aspx files - and a compiled DLL to the server. The DLL contains the compiled code so it doesn't exist on the webserver. The first user does not have to wait for compilation and the VB or C# source code is not on the server, potentially accessible to hackers.
It sounds like you've compiled the site to a DLL but that DLL isn't getting published to the server when you re-publish. Have you recompiled the site before publishing?
I faced similar issue with WPF single file exe publish.
while debugging from VS my changes were visible.
But when I pasted the exe to deployment folder, the changes weren't there.
I had to change the version number to see my changes when I run the exe from the deployment folder.
I may have to do with how single file exes are handled. The extracted cache may not be getting updated.
I have built a few custom applications that run on WSS 3 using the Visual Studio 2010 Web application template. When I compile the application, Visual Studio creates the assembly file in the bin directory which I copy over later to the production server (another machine) with WSS 3. The compiled application dll file is copied into the bin folder inside the virtual directory of WSS and runs fine in there.
As the project requirements / applications grew over time I now face the problem that the first hit on the assembly triggers dynamic compilation which I would like to avoid.
Even if applications are running fine I would like to use the asp precompiler on my development machine in order to reduce the delay when the page is first requested.
I have used the following command to precompile the entire Web Application:
aspnet_precompile -v / -p PATH_TO_WEB_APPLICATION C:\WebApp -errorstack
The compilation runs fine without any errors and I end up with a couple of .compiled files and also a Web_App_xxxxx.dll file inside the C:\WebApp\bin folder.
From here onwards I am a bit lost on how to proceed.
Could you please give me some advise to which folder I need to copy the compiled files on the production server ?
Do they need to go into the bin folder on the server or better into the folder where the aspx pages are located?
Additionally I would like to know if I can precompile the Web application on a development machine without the IIS metabase using the -v and -p switch and later use it inside WSS?
I copied all files from the C:\WebApp\bin folder to the server bin folder but unfortunately the csc compilation process still kicks in when looking with process monitor at the server events.
Cheers,
Mathias
The files just need to be dropped into the bin folder and everything will work fine. As for the -v switch you do need to have it if you're using the -p flag, but I think it depends how you're compiling the app too. Check this link out for more. I don't believe its a big deal if its wrong / incorrect though.
This kind of scenario sounds like a job for Cruise Control .NET environment.
I found an answer to this precompilation question:
I thought the first hit on the application page takes a long time because asp.net needs to compile it and I can save some time by precompiling. The application runs inside the WSS context and enables the user to go to a web form and update through the form his/her Active Directory profile. The Exchange global address list is also updated on the Exchange forest so the changes are visible through the Outlook address list and also on Communicator.
The complete solution code with reports etc is around 6000 lines of C# code.
My assumption regarding slow compilation due to the amount of lines was wrong.
I downloaded the following hotfix for asp.net:
http://support.microsoft.com/kb/961884
and set optimizeCompilations="true" in the web.config as explained here:
http://blogs.msdn.com/b/davidebb/archive/2009/04/15/a-new-flag-to-optimize-asp-net-compilation-behavior.aspx
http://www.paulliebrand.com/2009/09/18/sharepoint-development-to-bin-folder-and-extremely-slow-render-initial-render-times-solution/
Now the first hit on the application is much faster.
Many thanks,
Mathias
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.