[NHIBERNATE VERSION] : 1.0.2
[.NET RUNTIME VERSION] : C#(2.0)

We recently moved all our code over to Visual Studio 2005 and have noticed that projects that have a reference to the NHibernate DLL are compiling very slow.

When the reference is removed the compile time goes back to normal (fast), and when put back in, compiles slow again.

Has anyone else experienced this strange phenomenon?

I have experienced this problem. I reporting this problem on the developmentor dotnet_web mailing list; I am copying the conversation I had with Microsoft's Scott Guthrie below. My problem still remains unresolved.

---------------------------------------------------------------

I made sure that there were no version mis-matches with shared assemblies. I even deleted all the .refresh files.

However, the web project build is still taking about 3 minutes, something that took less than 10 seconds in VS 2003.

I am curious if I am the only one having this problem? I will appreciate any suggestions as this problem has caused a sharp drop in my productivity.

Would opening a support ticket with Microsoft help?

Thanks

Arvinder Chopra

-----Original Message-----
From: Discussion of building .NET applications targeted for the Web [mailto:DOTNET-WEB@DISCUSS.DEVELOP.COM] On Behalf Of Scott Guthrie
Sent: Tuesday, January 24, 2006 1:36 PM
To: DOTNET-WEB@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WEB] Building of Web Project Extremely Slow in VS 2005

[Resending again since I think it bounced the first time because of length]

Hi Arvinder,

Based on your description I'm almost certain it is the dueling references issue with two conflicting .refresh files.

Basically, the .refresh files within your \bin directory contain a pointer path to an assembly to dynamically refresh in the project anytime it changes. As part of this refresh process, it will also update and bring over other assemblies used by that target assembly if it has dependencies on it. For example, if you have a .refresh file pointing to AssembyA.dll which has a dependency on AssemblyB.dll, both will get copied over into your \bin dircectoy whenever one changes.

What can happen is that you might have two or more .refresh files pointing to different assemblies -- and that some of those assemblies are built and have dependencies on different versions of files.

For example: You have two .refresh files -- one pointing to assemblya.dll and one pointing to assemblyc.dll. Both have a dependency on assemblyb.dll, but the assemblyb.dll in their local directories are different versions. As such, you can end up "refreshing" and copying it over, and doing a clean build, everytime you do a build or hit F5. This will slow your build time down incredibly.

There are a couple of ways to fix it:

1) Make sure any shared assemblies that you have references to are in sync and don't have version mis-matches. This is the ideal approach and would be what I'd recommend unless there is some technical reason why they can't be versioned in sync.

2) Delete the .refresh files in your \bin directory. The .refresh files are only needed if you want to dynamically update the assemblies on changes. If you want to manually update an assembly, you can just delete its .refresh file (but keep the .dll).

If you can't fix the cirtuclar reference in #1 and/or don't want to loose the dynamic update capability by doing #2, you can kind of cheat the build system by creating a new utility library as a class project.
Have this utility class project reference these dueling assemblies, and then reference the utility project from your web-project. This will then cause all of the latest assemblies you need to be copied into the web project -- and avoid having the duplicate cause a reset each time.

Let me know if this works for you or if I can help more.

Thanks,

Scott

-----Original Message-----
From: Discussion of building .NET applications targeted for the Web [mailto:DOTNET-WEB@DISCUSS.DEVELOP.COM] On Behalf Of Arvinder Chopra
Sent: Tuesday, January 24, 2006 11:48 AM
To: DOTNET-WEB@DISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-WEB] Building of Web Project Extremely Slow in VS
2005

Scott

I set the Build verbosity level to Diagnostic, and the output is attached below. You can see that building of the web project takes close to 4 minutes and almost all of that time was spent in validating web site; I had not changed any code in the web project from the previous build.

BTW, what is the dueling references issue, and is there a way I can fix it?

Thanks

Arvinder Chopra

===================================
This list is hosted by DevelopMentorR http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

===================================
This list is hosted by DevelopMentor® http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

This seems to make sense.

When I added a reference to a dll in VS2003, the reference path for the project was updated to show this. It appears that VS2005 doesn't make the same use of the reference path (at least none have been set in the projects in the solution I'm working on), it just seems to remember the path to each reference individually.

I have 3 helper dlls (based on the best practises doc on code project) which deal with all my NHbernate plumbing (domain super class, manager base class, session module and interceptor), but I also need to reference the NHibernate.Generics dll in the web app (for strongly typed collections). The Generics dll (which refs Nhibernate etc) is in a central project references folder, however the helper dlls (which also reference nHibernate) were referenced from the build folder of the helper solution.

I removed the references to the helper dlls, copied them to the central refs folder, re-referenced them, and did a rebuild solution. Result: build took 30-45 secs (still too long), but way shorter than the 4+ minutes (sitting on validating web site) it took before.

definately progress though.

Mark

AFAIK, the "new" way net 2.0 handles web projects is just horrible. You might want to try out the Visual Studio 2005 Web Application Projects, it brings back web projects like they were in VS2003.
AFAIK, it shoud also be included in fortcoming VS2005 update (or SP)...

Gert

Yeah my colleague is using it just now.

I'm still not convinced the old way was better (or that the new way is any good either).

It was easier having namespaces in web projects, and this mini dev server is proving to be a right pain (try having parent paths for css/images etc to use the standardised inhouse look and it just won't work).

I do like the idea that a folder structure on disk can be a web app (I still have hundreds of decomissioned old projects/prototype sites on my main dev box in iis manager).