Recently, I had been experiencing a very annoying problem regarding my project’s publishing. In my company it is a common practice, that we publish the website we are going to deploy, to a local folder with “Single File Assembly” option ON and then upload the necessary files that has been changed via FTP to the staging or production server. Recently, when ever I was tying to publish the website, Visual Studio was giving output after trying to pre-compile as --
|“Object <436114d4_6fca_4720_9ef7_fcd21e349d9d>/<Z3qAWE53tdTYmJNo8I3Wn6ys_320>.rem has been disconnected or does not exist at the server.”|
(The alpha-numerics are random of course as it seems to be.)
I googled this problem and found an interesting fact that was causing the problem. When pre compiling, an object was being created and as the publish is taking too long to execute, the object is being Garbage Collected and as a result the object becomes unavailable to the process. So, I found out the “project building time” was the main culprit here. The project I was working on is pretty large (~6.66GB) and I never dared to press F5 while trying to test something because if somehow I pressed F5, I had to go for a coffee and sometimes, even after my coffee break of 15-20 minutes I had to come back only to find the build is still going on….
The Search of Solution
Finally, I got frustrated and searched desperately to solve the problem. One solution I could think of was to increase the RAM of my machine and that required organization’s approval. I have 1 GB of RAM in my machine and I am running Windows XP Service Pack 3, I thought it was enough of RAM for a machine running XP and Visual Studio 2005. Anyways, I opened the system properties box by right clicking on “My Computer” and clicking on “Properties” in the context menu. Went to “Performance” section and selected the radio button which assures to give “Performance” the highest priority. More over, I killed some unnecessary processes from Windows Task Manager - especially the “Search Indexer”. Now my machine was faster than lightning! So I started publishing again.
“Object <some alphanumeric>/<some_alphanumeric_number>.rem has been disconnected or does not exist at the server.”
Duh! So much for doing so many things. I started searching again. And this time God said “Let there be light…” and of course .. ”there was light!”.
After a long search I detected the culprit of the “long building time” mischief. This was being generated by some conflicting dll.refresh files.
When ever someone adds a reference of an assembly to an application the dll.refresh file gets generated automatically. This .refresh file actually saves the relative path for the original dll file from where the dll file was referenced. At the time of building, the Visual Studio check those dll.refresh files to find whether any updates has been made to the original dll file and if it finds an update, then it automatically updates the referenced ones too accordingly. If there are dependent assemblies, then Visual Studio also copies them too to the bin folder.
So to restrain Visual Studio from auto checking the updates, the dll.refresh files can be deleted which in turn solved my long building time problem. Believe me, the building time change was drastic.
This I think is a good solution to the slowdown problem because, even if the original dll gets updated you can always make a reference which will update your application. Generally within short term projects we do not change third party dlls very often, so they can be deleted without any hesitation. Of course if you have used a class library of your own which gets changed every now and then, it is better to keep the refresh file intact. So, what was the problem and where is the conflict?
Scott Guthrie, calls this problem the Dueling Assembly Reference Problem. You can get a wonderful detail in his blog here.