Daily Static

Technology, Dynamic Programming and Entrepreneurship

This page is powered by Blogger. Isn't yours?
Wednesday, April 23, 2003
Visual Studio Update

Ok, I spent some time reveiwing what was happening in Visual Studio,
and I've revised my opinion. I don't think it has anything to do
with licensing, or if it does it's only a tertiary issue. It appears
that our problems were related to a buggy build order in Visual
Studio .Net. In order to make CVS use easy for all of us, we have
standardized on output directories for our dlls in the following


this allows us to add a reference to our project and have it still
work when compiled on another developer's machine. The problem we
were running into is only happening with solutions containing
multiple projects in a hierarchy. Here is an example:

c:\shared\debug\bin\thisusescore.dll <- core.dll
c:\shared\debug\bin\thisalsousescore.dll <- thisusescore, core.dll
c:\shared\debug\bin\anapp.exe <- thisusescore.dll, thisalsousescore.dll

our hierarchy is significantly larger than this, however the issue
is thus: building core.dll works fine, and building up the tree works
fine most of the time. The "<-" symbol indicates that a dll is
compiled into the project to the left of it. Because anapp.exe
references thisusescore and thisalsousescore we will occaisionally
have problems building the solution because thisalsousescore is
read-only. This seems to happen only when thisalsousescore becomes
sufficiently large. Ultimately it could have still been the licensing
that caused this problem, because when the license file was added to
my machine and another developers machine the error began occurring

The fix we implemented was to compile all dlls to
c:\shared\debug\lib. anapp.exe references the dlls in the lib
directory, but is set to copylocal (moving a copy of the dll to the
bin directory to run). I know this explanation is a little
convoluted, if I come up with a better example I'll post it.

Comments: Post a Comment