I get an error when ever I replace a user control, or dll on th website. The solution is to stop iis and delete the contents of the folder, obviously not ideal to stop the site.
I read that this might be caused by class names being reused, as in when you make a copy of a control and add it to the solution.
Is it typical for this folder to be used, how can I avoid the site crashing whenever I make a change
Running on IIS7.0, ASP.NET 3.5
I get this problem if I update DLLs and don't clear out the BIN folder, because of the way my code is setup. For example, if I am using version 3.0.1 of a DLL and I add version 3.5.0 of that DLL, it causes conflicts.
As far as a solution, I would agree with the first answer though, which is to have a dev server and a live one, and publish up, although it may not be ideal for your situation.
you should separate development from production, and publish from dev to the prod iis.
btw, in case you actually have 2 classes with the same name, compilation should fail this way.
Use publish to publish the site, consider precompiling. The temporary folder is where resources compiled on the fly are cached.
Faking a web.config update to generate recompilation might also work as opposed to IIS restart? Though not ideal.
Related
I have faced a lot of issues with Publishing like when you need to make small changes on the code, sometimes the generated DLL file (the dll file for example of default.aspx.CS when published) cannot be recognized by IIS saying the codebehind is wrong or something. Sorry for not remembering the exact error message. I am hoping you know what I mean at this point.
Therefore, I usually do a simple Copy Paste operation instead of Publishing.
Could you tell me what am I missing by NOT using the Publish method? How is Publishing better? Or which one do you prefer, why?
Basically its a pros and cons situation.
Thankyou
Well, it depends on what you mean by "copy":
With Publishing you have options to pre-compile all or part of your application. You can publish to a local folder in your file system (instead of your target/host) and then copy the updated file(s) (only). If you are making "code behind" (c#/vb code) changes, this means you'll likely only need to "copy"/overwrite dlls. Goes without saying that if you've made "content" changes (html/razor/script/etc) changes, then you'd need to copy/overwrite those as well.
If you're new to deployment, you may find yourself simply copying/overwriting "everything" which is the safest way to go. Once you get more experience, you'll "recognize" which assets you only need to update (one or a few dlls and or content code, instead of "everything"). There's no magic to this, usually, its a matter of just looking at the timestamp of the dll/file after you've published (locally) or rebuild your web application.
I'd recommend doing a local publish so you can see what is actually needed on your server. The files published to your local file system/folder is what needs to be on your host/server. Doing so will visualize and remove whatever "mystery" there is to Publishing:
you'll see what is actually needed (on your server) vs. what's not
you'll see the file timesstamps which will help you recognize what files were actually changed vs those that weren't (and therefore don't need to be updated).
once you get the hang of it, you will not need to "copy"/ftp "everything" and just update files that were actually modified (only).
So "copy" can mean the above, or if you are saying you will simply copy all of your development code (raw (vb/cs)html/cs/vb) to your host, then that means your site will be dynamically compiled as each resource is needed/requested (nothing is pre-compiled). Also "easy" but you do lose pre-compilation which means there is a delay when each of your web pages are requested/needed (ASP.net needs to dynamically compile). Additionally, you are also exposing your source code on the server. It may not mean much depending on your situation, but it is one more thing to consider.
Here's more info on pre-compilation and options.
Assuming we consider an aspx page and its aspx.cs code behind file, there are three alternative ways of deploying your site:
You can copy both to iis. The aspx will be compiled to .cs upon the first request and then both .cses will be compiled to a temp .dll
You can "publish" to iis, this will compile the code behind class to .dll but will copy the aspx untouched. The aspx will be translated to .cs and then to .dll upon the first request
You can "publish" the site and then manually precompile it with the aspnet_compiler. Publishing will compile the code behind to .dll as previously but then precompilation will clear out your .aspx files by removing their content and moving the compiled code to yet another .dll.
All three models have their pros and cons.
First one is the easiest to update incrementally but in the same time is the most open to unwanted modifications.
Second is also easy, can be invoked from vs, it closes the possibility of some unwanted modifications at the server but .aspxses still need time to compile upon the first request
Third takes the time and some manual actions but prevents any changes and also speeds up the warm up of the site as the compilation of assets is not necessary. It is great for shared environments.
So I'm left maintaining a proprietary codebase from a third-party vendor. The vendor is still sort of around, but support is limp. The site is ASP.NET.
I have made some changes but I am having a really hard time getting IIS to compile these changes in. The bin/ directory has what I believe is a precompiled dll for the core classes. I've changed these but it doesn't recompile. I have tried deleting the dll but then the app refuses to build saying that the Global.asax can't inherit the type anymore, so I don't really know how to rebuild with changes.
I spent all day Saturday setting up a build environment and trying to get a testing thing working. I have just been importing into VS2008 as a web site from the local IIS server. I got it to rebuild the app without changes, but it ignores changes I would place in it.
So I need to make a solution out of this website and/or directory structure so that I can do actual, big, full grown-up rebuilds and make changes to this codebase. Anyone know how I can go about this?
EDIT: A bit more elaboration. I've tried creating a blank project and just Add Existing File... on the whole website directory. This hasn't worked, it stops the import about 10% in.
Keep in mind there are two (actually, three) levels of 'builds' or compiles going on here.
1) The DLLs in the /bin directory should be pre-built, by visual studio or otherwise. The content of .ASPX, ASCX, ASHX, ASAX etc fiels are not included in those.
2) The ASPX, etc files I noted above are then compiled by IIS when the first request comes in (normally; there are ways to change that behavior). That is the source of the error with Global.asax you are seeing; With the DLL(s) gone, the class that Global.asax is supposed to inherit from does not exist.
3) Then there is the just-in-time compilation, which is not relevant for this discussion.
It sounds like you may be missing the source files for the project, or perhaps the web site is not getting properly set up as a project to compile that DLL
Try these links, I suppose this is what you are looking for.
http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2010/01/20/linking-files-in-visual-studio.aspx
http://support.microsoft.com/kb/306234
Not sure this question is really valid anymore. The source we were working with was rather different than it should have been. Not sure if someone got angry in the past and moved stuff around or what, but grabbing a new copy of the source fixed most of our issues. I am able to build now with an included csproj.
This doesn't really help many others with the same issue I suppose, but if you are getting weird build behavior like this, you might want to start with basics, like making sure that your source checkout is valid.
I am new in asp.net so I am not sure it is a professional way or not.
I have the project without .snl file. I just create a empty web site and then paste the files inside the folder where I created the project.
It worked for me.
I think pasting the files and folder directly by file manager will help you.
Is it possible to exclude a folder in a web project from being published? We've got some documentation and scripts that included in a particular project folder, and are added to the project, but when I do a VS publish, I don't want them to go up to the production server.
I know they shouldn't be in the project, but I thought I'd find a workaround before I try to convince the owner to modify the way he's doing things.
Old question, but I found if I mark the folder as hidden in Windows Explorer, it doesn't show/publish in your solution.
This is good for example to stop original photoshop images being included in uploads which aren't used and are big. Anything more complex though you'll probably want to write your own publish tool.
This doesn't answer your question, exactly, but my feeling is that unless you are a single developer publishing to a server, you would be better off doing builds on a dedicated workstation or server using MSBuild (or some other building and deploying solution) directly (and thereby would be able to very granularly control what goes up to production). MSBuild can not only build, but using some extensions (including open source types), it can also deploy. Microsoft has a product called MSDeploy in beta, and that might be an even better choice, but having no experience with it, I cannot say for certain.
In our situation, we have a virtual workstation as a build box, and all we have to do is double click on the batch file that starts up an MSBuild project. It labels all code using VSS, gets latest version, builds the solution, and then deploys it to both servers. We deploy exactly what we want to deploy and nothing more. We're quite happy with it.
The only downside, if it could be considered a downside, is that at least one of us had to learn how to use MSBuild. VS itself uses MSBuild.
For the files you don't want to go, loop at the properties and set the 'Copy to Output Directory' to 'Do not copy'
This option is not available for directories, however.
Can you not exclude them from the project through visual studio to stop them being published. They will the still exist in the filesystem
The only way that you can do this to my knowledge would be to exclude it from the project, do the publish, then re-include it in the project. That can be an issue.
There are probably much better ways to solve this problem but when we publish a build for our dev servers, we'll run a batch file when the build is complete to remove the un-needed folders and web.configs (so we don't override the ones that are already deployed).
According to http://www.mahingupta.com/mahingupta/blog/post/2009/12/04/AspNet-website-Exclude-folder-from-compilation.aspx you can just give the folder the "hidden" attribute in windows explorer and it won't publish. I tested this and it works for me.
Seems like a straightforward solution for quick and dirty purposes, but I don't think it will carry through our version control (mercurial).
Select all the files that should not be published.
Go to Properties
Set
Build Action -> None
Have to repeat the process for each sub-directory.
I have an ASP.NET 2.0 application (installed on IIS 6.0 from an MSI) which was compiled as a "web site", and precompiled/packaged using a web deployment project, in Visual Studio 2005. (I have put in a request to the developers to consider changing to a web application for the next version, but it won't change for this version).
Whenever the application is recycled (e.g. a change is made to the web.config), on first hit, ASP.NET JITs the application. As part of this, it takes all the assemblies required for the login page and compiles them into native code in the Temporary ASP.NET Files 'assembly\dl3' directory, which takes between 20 and 60 seconds. This only happens on a recycle, which happens infrequently — but when it does, it causes the page to take much longer to load, and I believe it may be possible to optimize this.
There appear to be 122 DLLs that it needs to consider, some of which are the precompiled code-behind, others are third party components for the web site (for example, NHibernate.dll, reporting components, etc.)
Why does it recompile/re-JIT everything? Why does it not detect that most of the assemblies have not changed, and not attempt to change them? Can I prove it's not batch compilation that is causing the problem? (I have <compilation debug="false"> set in the web.config.)
Other questions suggest NGEN might be useful but I read it's not possible to use it on ASP.NET 1.x; we are using 2.0 and I can't find a clean answer either way.
From my personal experience slow recycle is often caused by NHibernate/ActiveRecord if you have lots of entities. See http://nhibernate.info/blog/2009/03/13/an-improvement-on-sessionfactory-initialization.html for explanation + possible solution.
Are you running IIS? I'm fairly certain that if you restart your site in IIS it will pick up any changes to configs without copying the dlls.
You may be able to improve your recycle time by installing common DLLs that change infrequently -- such as NHibernate or reporting tools -- into the GAC. That should prevent them from being re-jitted.
How to: Install an Assembly into the Global Assembly Cache
It's strange that only copying the dll takes 20 seconds. I would suggest to do another check and make sure where the bottleneck is.
How can you be certain that everything is in the proper state without recycling/resetting (or whatever happens) the AppDomain? Imaging that you have something in application start (global.asax) which sets the value of a static field based on a config value. Unless you reset the entire AppDomain you cannot be sure.
Another reason: There is no way to unload a .NET dll once its loaded, so you have to recreate the app domain when something is updated.
I have a solution with several projects in Visual 2008, let's say SuggestionProcessor (a class library) and Suggestions (a website) with a webhandler GetSuggestions.ashx. I changed a method in SuggestionProcessor which is used in the webhandler. The call in the webhandler has been adjusted to the changed method.
But now when I try to execute the webhandler after a rebuild I get an error that the method I changed is missing, displaying the old method signature. When I try to rebuild the entire project it seems that the website does not rebuild properly and the code I changed in the webhandler does not seem to be included in the rebuild. I made sure that the website is last in the build order.
What I tried is remove the dlls that the build process should rebuild from the bin folder (not the ones referenced from outside the website). When rebuilding I now get a: 'could not load type Suggestions.global'. Duh, that is what the build process should create. What is going wrong here?
I solved this one by reverting to a previous state when it still worked.
Thanks for the suggestions, I'm sorry they didn't work in my situation.
Shall I delete this question now that it doesn't really have a clear use for someone else?
I would check your web.config file, there may be references there that are causing the error since they are missing.
Maybe try and right click on your solution and select "Clean solution" and then try and rebuild all.
If that doesn't work, check your solutions build configuration and make sure all your projects are getting built
Try "Clean Solution", then building SuggestionProcessor, and after that clean and rebuild the web solution.
Visual Studio creates a copy of all your DLLs and sometimes this copies are not refreshed.
Just execute iisreset and delete all folders in:
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary
ASP.NET Files\
Of course change windows installation folder and framework folder to your version!
I don't think so... I've seen similar issues in Visual Studio 2008 working on web projects where the build and rebuild would fail time after time. I knew that my changes shouldn't have affected the build so I just kept cleaning and building each of the individual projects in my solution until finally (and I do mean finally as in, it took up to 10 builds) my web project would build correctly. I have no idea why, but it feels like some sort of caching issue.
From my answer at "Could not load type [Namespace].Global" causing me grief:
It seems that VS 2008 does not always add the .asax(.cs) files correctly by default.
In this case, refreshing, rebuilding, removing and re-adding, etc. etc. will not fix the problem. Instead:
Check the Build Action of Global.asax.cs. It should be set to Compile.
In Solution Explorer, Right-click Global.asax.cs and go to Properties. In the Properties pane, set the Build Action (while not debugging).