When I add a reference to an assembly (living in the GAC) to web.config in an ASP.NET project, what does Visual Studio do?
[This is related to an earlier question pertaining to BusinessObjects: VS2008: Projects now take forever to open ]
When I add "CrystalDecisions.Enterprise" and "CrystalDecisions.Enterprise.Framework" to the assemblies element in web.config, VS thinks long and hard about it, locking me out for a couple of minutes while it scrutinizes the newcomers.
What is it doing during this time? I Googled this but came up empty.
I can make some educated guesses (IntelliSense integration, perhaps?) but would ideally like to find some documentation describing exactly what's going on.
Ultimately I'm hoping to learn why these BO references are making VS take several minutes to open my projects (I struck out on the SAP forums).
I can't help you directly with finding documentation but Visual Studio will need to load these assemblies into memory and navigate the assembly structure for many different things, such as Intellisense population, Object Browser, etc. It will also have to potentially load other GAC items that those assemblies depend upon into memory and do similar things.
Related
I have an ASP.NET 4 web application that references a SOAP web service. I have an (old fashioned) Web Reference to this web service in my project. When I compile/build in the IDE I get no problems and Intellisense and the Class Viewer all show me that VS knows what is what and where to find it.
However, when I run the solution, I get this error:
The old CS0234 error (The type or namespace '<...>' does not exist...). Intellisense begs to differ.
My web app assembly is called NovaWeb and my Web Reference is called WS3. I can see that my Reference.cs file contains the following:
namespace NovaWeb.WS3 {
This was all working great a little while ago, but I apparently changed something and now everything is broken. I've tried cleaning out all of the files in the /bin folder and all of the temporary ASP.NET files in my appdata folder.
Does anyone have any suggestions about how I can troubleshoot this problem?
EDIT: My Work-Around...
I've still got the troublesome project laying around in case someone suggests an answer. I can give it a try to see whether a resolution exists. In the meantime, I couldn't wait for a real resolution so I've taken a work-around.
What I've done is started from scratch with brand-new VS2010/.NET 4 web application projects and moved my source code files over into the new projects piece by piece. There are a few salient differences between the busted-down solution (.sln) and the work-around solution. These are:
The work-around has one solution (.sln) per project. The problem solution had two web applications and three EF4 data library projects in a single .sln.
The work-around solution was started from a green field (empty ASP.NET Web Application) template within VS2010 and targeting .NET 4.0 from the outset. The problem solution had parts that began life in VS2008 and originally targeted .NET 2.0.
The work-around project completely avoids any hint of an App_Code folder. The problem solution had a project with an App_Code folder containing a few utility classes. I'm not sure that this makes the slightest difference, but I did run across at least one posting that suggested the compiler might be confused by a code folder called App_Code in a web application project.
"I gave up and started over" is not much of a resolution to a problem, but I thought I would leave it here, along with this question - in case someone happens by with a solution or in case it is at all helpful to the next person with the same problem.
I'm not usually one for answering my own questions. However, this question has been open with no answers for over a month. It's had a decent number of views, which makes me wonder if others might not have the same problem. Since I've finally found the solution, with the help of some direct support from Microsoft, I thought I would document my solution in case it helps the next person to stumble on this error.
So it turns out that web services is a red herring with this problem. The real crux of the issue is the runtime CS0234 error relating to a referenced type. It can also manifest itself as a runtime CS0103 error too, as I found out the hard way.
I mentioned in my question that I found a work-around. The work-around eventually stopped working and I was out of the water on this project. I contacted Microsoft for support and after four days with my source code they came back to me with a solution.
The problem was related to my compiler configuration for target platform.
Due to some agony that I've suffered in the past over deploying multi-assembly applications on the desktop, I have gotten into the habit of changing my build configurations from Any Platform to x86.
This can apparently mess up your compile for an ASP.NET web application. That smells badly like a Visual Studio bug to me, but nevertheless, the solution to my runtime error was to go to the Solution Properties (not project properties) and to select Any Platform for the build target.
I hope this saves someone some aggravation. If anybody has a reasonable explanation as to why this is not a VS bug or what is going on under the covers, I would be interested to hear it and I promise to upvote you for your trouble!
What is the best practice for not breaking builds for team members working on asp.net website code base using TFS?
I keep seeing a single developer adding a reference to get their code to work and checking it in, then when everyone else gets latest version they lack the reference on their dev machines and get broken builds and have to waste time hunting for resolutions.
Aside from emailing the team when someone adds a new reference is there something inherent to VS that can be used?
Can we pull a separate project and refer to that as a redundancy and keep all resource dlls and references there?
The Visual Studio Team Foundation Server Branching Guide 2010 describes many working scenarios. It's long but worth reading.
Guidance for Structuring Team Projects
I've always kept third party DLLs in a project folder under source control, so that a get-latest pulls them down.
Of interest?: Visual Studio 2010 Quick Reference Guidance
I've been working on a legacy ASP.NET Web Site (versus a Web Application) project at a client for some time now, and its slow compile time has me wondering:
Are web site projects known to be slow(er) at compiling (than Web Application projects)?
It's a pretty small website, but the entire solution has tons of functionality -- 19 projects worth of it, 18 of which compile really quickly (the non-web projects). The website project itself has ~100 pages and ~15 user controls (these actually take about half of the compile time) and normally compiles within 30 to 60 seconds. A complete re-build takes closer to the latter.
So, some things I believe could be slowing it down (you debunk them):
(X)HTML validation issues (the code we inherited has thousands of compiler warnings about validation issues).
High levels of abstraction -- since the code for the website pages is compiled at run-time, I'm guessing that whatever it's doing for user controls up-front is a lengthy process so that the binding at compile-time can happen.
The mere size of the web site? I know these are not very efficient projects, and believe me, I've spent hours trying to get it converted to a web application, but Visual Studio was unable to parse a single ASPX file into its .aspx/.designer.xx components because of the validation problems I mentioned earlier.
Assuming my client won't approve more than a few hours to fix this up, is there any quick fixes, changes, or optimizations known that could help me out?
I do not have a puny computer, so its processing power is not an issue. I've also worked on Web Application projects equivalent in size and complexity that compile in just a few seconds.
I'm open to pretty much anything, so I'd love to hear your thoughts! Also, if you think this should be a wiki, let me know.
My observations have been the same: web site projects take awhile to build, longer then web app projects. I think I found some information on why, check this out: http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx
Search for "Iterative development". It says this about web site projects, when compared to web application projects:
By default, Visual Studio completely
compiles Web site projects whenever
you run or debug any page. This is
done to identify compile-time errors
anywhere in the site. However, a
complete site build can significantly
slow down the iterative development
process, so it is generally
recommended that you change the build
project option to compile only the
current page on run or debug.
First read this blog post Tips to optimize design-time build performance for Web Sites in Visual Studio 2005
Main points made:
Do not disable batch compilation
Leverage Server-side Compilation
Move App_Code files into a separate class library project
Check for conflicting dependencies
Turn off AutoToolboxPopulate in the Windows Forms Designer options.
Disable validation for HTML editing
Another option that could help you is switching to a RAM disk: Running development from a RAM disk – options and products
If that doesn't help maybe splitting your large WAP into multiple ones could improve compile time. Unfortunatelly that strategy requires you to drop developing on Cassini. Instead you will have to use IIS as host: Using multiple Web Application Projects (WAP) in one Solution
One fact most developers overlook in an ASP.NET Web Project is the amount of classes in the App_Code folder.
The more classes you put in it, the longer it will be the compilation time.
From the ASP.NET Compilation Overview on MSDN:
ASP.NET creates an assembly for each
application directory (such as
App_Code) and one for the main
directory. (If files in a directory
are in different programming
languages, then separate assemblies
will be created for each language.)
So, if you can basically minimize the Folder Hierarchy and reduce the amount of classes in it, it will probably reduce the compilation time.
Another thing I noticed from your post is that, you have 18 non-website projects.
I think it is a bit too excessive because think of it this way.
When the Web Project compilation starts, the ASP.NET Compiler needs to link the 18 separate DLL files.
If those projects can be combined to reduce the number of DLLs, it might help also.
From maintainability viewpoint, having 18 projects is a bit excessive unless there are REAL strong reasons to do so.
I would suggest reviewing the projects and combine them.
I hope it helps.
This may not be ideal, but you can split your projects into multiple solutions. For example you can take the user controls and put them in Solution A and the rest of projects into Solution B. Then compile the controls in Solution A and file reference to them from Solution B which should help cut down the compile time
Website or web project, the performance should be similar after compilation phase. If the issue is poor performance immediately after deploying a new set of codes, a quick way I can think of is to pre-publish the site. (see reference http://msdn.microsoft.com/en-us/library/1y1404zt(VS.80).aspx)
Depending on the options you choose during the publishing, you may lack flexibility to make changes on the fly (which you shouldn't anyway).
I have looked through the related questions, and none of them have provided me the information I am looking for.
Currently the team I work on does deployments of individual .aspx (and .aspx.vb) files for bug fixes/enhancments. I am trying to affect change, as I really believe that deploying the "whole compiled site" is less error prone. As this is a significant change from the way things have been done, my suggestions have ben met with significant resistance.
As my google-fu has not been up to par lately, I was hoping the SO community could either tell me that I am off my rocker, and that there is nothing wrong with moving individual files, or point me to some really good resources which would allow me to make a stronger case.
Edit:
This has all been great info, and reinforces the arguments that I have already been making, can anyone argue the other side?
Deploying individual files for bug fixes and deployment is not a wise strategy. It sounds like you need a comprehensive build and deployment process. That doesn't mean it has to be complicated as there are some good tools available nowadays.
Build and deployment can get detailed, so as a minimum start try taking a look at the Microsoft Web Deployment Tool (http://www.iis.net/extensions/WebDeploymentTool). Install the tool on your build server and install it on your deployment server. Stage your ASP.NET content locally using the Visual Studio Publish command, then use the above tool to synchronize the entire package on the deployment server. I like this approach because it can be completely automated. When doing builds and deployments, aim for complete automation to reduce potential errors.
This is the bare minimum, but you will at least be certain that when specific files are changed, they are ALL synchronized on the deployment server.
Personally to me rolling back immediately is most important. Again website projects are very hard when it comes to track the changes.
you can find a good detailed comparison here. I am reproducing the article here.
1) Deployment. If you need in-place deployment, this model is perfect. However, it's not recommended since you are exposing your logic in clear text. So, anybody who have access to physical server can mess with your code and you never going to notice this. You can try to make precompiled web site, but you going to end up with a lot of dll and almost untouchable aspx files. Microsoft recognized this limitation and released Web Deployment Project tool.
2) You need to keep track of what did you change locally and what did you upload to production server. There are no versioning control. Visual Studio has Web Copy tool, but this tool fails to help. I had to build my own tool, which kept track of changes based on Visual Source Safe.
3) When you hit F5 for debug execution it takes merely 2 minutes to compile and execute whole project. Of course you can attach debugger to existing thread, but this is not an obvious solution.
4) If you ever try to generate controls on a fly you will hit first unsolvable limitation. How to reference other pages and controls. Page and control compilation happens on a per directory basis. On best case you going to get assembly for each directory, in worst each page or control is going to get its own assembly. If you need to reference another page from a control or another page you need to explicitly import it with the #Reference directive.
So for,
customControl = this.LoadControl("~/Controls/CustomUserControl.ascx") as CustomUserControl;
You need,
But what if you want to add something really dynamically and can't put all appropriate #Reference directives? Or What if you are creating server control and it doesn't have ascx file, so you don't have a place for #Reference ? Since each control has it's own assembly, it's almost impossible to do reflection.
Web Application Projects which re-appeared in Visual Studio 2005 SP1. They solves all issues mentioned above.
1) Deployment. You get just one dll per project. You can created redistributable packages and repeatable builds.You can have versioning and build scripts.
2) If you did code behind change you can upload just one dll. If you did aspx change you can upload just aspx change.
3) Execution takes 2-3 sec maximum.
4) Whole project is in one assembly, which helps reference any page or control. Conclusion. For any kind of serious work you should use Web Application Projects. Special thanks to Rick Strahl for his amazing article Compilation and Deployment in ASP.NET 2.0.
I agree with Rich.
Further information:
Deploying your SOURCE code ala the .vb files to the server is a BAD idea. Compile it. Obfuscate if you can, just don't deploy straight source. Imagine an attacker which gains access to the system. They could easily change your code and you might not ever notice. Yes, you can use a tool like reflector to decompile. But it's really hard to decompile a full site, make the changes you want, and put them back into production.
Deploying a single file might very well cause some type of problem in a related module. I'm guessing you guys don't really do QA. Tell them it's time to grow up.
Compiling your site will reduce JIT (just in time) compilation. Think performance.
I'm also going to guess that pretty much everyone has production server access. This is bad from the company's perspective as you have no controls in place. What happens when an employee decides to cause some havoc before leaving?
What you are describing is inline with Cowboy coding. Sure, it's fun to ride to the rescue but this style frequently blows everything up.
It's bad for rolling back. If you deploy as a web site vs web app, yeah you can do quick patches of one or two files, but what if you ever need to roll back to a previous version? Good luck tracking down all the files that were updated to make the new version. I much prefer the concept of a "version" for organizational reasons, and the compiled web app is much more inline with this than a "website" project.
We had this dilemma and ended up going with the compiled version mainly for the security reasons. If your site is external facing you could be compromising your security by allowing the vb files to be out there in plain text. I realize one could still get your code if they really wanted to but it would be an additional hurdle they would need to go through. If you use Visual Studio as your development environment you can publish the site pre-compiled and check the named assemblies option when publishing and this will essentially create a dll for each aspx page so you can do the one off page changes if necessary. This was a great feature we found as we were constantly updating the whole site and there were times when things would get updated that shouldn't. After using that feature we no longer had updates getting pushed that shouldn't. As far as rolling back I hope your using some type of Source control / versioning system. Team Foundation Server is great for versioning/source control but it is quite pricey.
What is the best deployment strategy depends a lot on what kind of environment you are working in, and what kind of developers you are working with.
Visual artists that started with graphic layout and worked towards programming are much more in tune to individual page generation and release. Also the .aspx.vb files are simply server side scripting, not really programming.
Programmers usually start at the command line and branch out to environments such as the web and understandably feel that good programming practices should be applied too the web, including standard test and release cycles (and compiled code).
If the site is in constant flux the individual pages would make more sense, but if you are required to deliver an installation package to your production group msi files are the way to go, since they can be easily backed out if necessary.
If you evaluate what your groups needs are, which includes the varied experience of everyone in your group, you should be able to convince either yourself or the group. This is not a matter of which is better, but which provides the best business model.
I've just built a crap load of Telerik reports for my web site project, and they all work nicely. I have to demonstrate them tomorrow, and tried to build a viewing page that hosts their web ReportViewer. I have asked this question on their forums as well, but expect less response than from SO late on a Friday night.
Whether I use GAC or bin references, as soon as I add the ReportViewer control to my page, even without trying to load a report, I get the error Failed to map the path '/'. Other Telerik controls, from the Web.UI library work fine. I'm not expecting a Telerik specific answer here, although that would ease the pain of my all-nighter, but I can see nothing meaningful in the stack trace for this error.
How can I go about diagnosing what Telerik is looking for and can't find, or something of that ilk? This is a serious emergency, and I will sort a 'dereferenced' bounty for anyone that can offer any suggestions tonight. I'm going to reinstall Reporting so long.
UPDATE: Foolishly wary of excess complicating factors, I always try new things like this in a small, dedicated project separate from my main one. Yesterday I quickly tried a small web site project when I encountered my problem. I then tried a small web application project, with local, not GAC references to telerik, all telerik refs set to copy to local, and it all worked. Naturally I was quite ecstatic, as my main project is a web app, not site.
so you have a webpage running without problems.
Than you add a telerik ReportViewer controls - run the things again and get an error:
...Failed...'/'...
The control simply sits in the page and does nothing.
So like womp I would ask you to provide the full error output!
One other question:
Does the error also occure on the development machine (running the project from VS with webdev server)?
And a hint meanwhile (not sure if you'v already checked this):
http://www.telerik.com/support/kb/reporting/general/deploying-telerik-reporting.aspx
One last thing - maybe it con help you. I made up a little web site doing what you have told your site does.
You can download it here: www.pp-p.com/rvsite.zip
Maybe a look at web.config or so can help you to find what's missing in your site.
One thing - in the BIN folder are two txt files - replace them with the DLLs from telerik reporting to have the project work.
Maybe this helps (for the weekend till the telerik support guys are back at work)..