C# project reference problems (reference pulled from obj folder, not bin folder).

[Richard J Foster]

Hi there,

I have a pair of C# projects in VS2003. The first project, a dll, is
referenced in the second via a project reference.

The assemblies in question are delay-signed during a "production " build
process, but not as part of a normal development build.

I have noticed that while the correctly signed assembly is present in
the designated output folder for the project (e.g. bin/Release), an
unsigned version is also present in an obj/Release folder.

Even though the library has been built and signed correctly, the
project which references it is grabbing the unsigned version of the
library from the obj folder. Within VS 2003, the properties display for
the project reference even confirms that it is coming from the obj
folder, instead of the expected source - the designated output (bin)
folder.

1) Is this the expected operation? (I don't believe it used to work
this way, and have not intentionally changed anything)
2) Is there any way to still use project references, but pull the
referenced dll from the designated output folder (i.e. bin/Release)?

Thanks in advance,
Regards,
Richard

[Peter Bromberg [C# MVP]]

Richard,
I have seen junior developers where I work who are reallyreallydum b set hard
references (not Project references, which are recommended) to the output in
the /obj folder.

I have no earthly idea what their logic was; normally build output is
directed to the /bin folder. That's best-practices. the obj folder is really
a temporary intermediate build output "work" folder and should not normally
be the target of the finished build.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Richard J Foster" wrote:

Hi there,

I have a pair of C# projects in VS2003. The first project, a dll, is
referenced in the second via a project reference.

The assemblies in question are delay-signed during a "production " build
process, but not as part of a normal development build.

I have noticed that while the correctly signed assembly is present in
the designated output folder for the project (e.g. bin/Release), an
unsigned version is also present in an obj/Release folder.

Even though the library has been built and signed correctly, the
project which references it is grabbing the unsigned version of the
library from the obj folder. Within VS 2003, the properties display for
the project reference even confirms that it is coming from the obj
folder, instead of the expected source - the designated output (bin)
folder.

1) Is this the expected operation? (I don't believe it used to work
this way, and have not intentionally changed anything)
2) Is there any way to still use project references, but pull the
referenced dll from the designated output folder (i.e. bin/Release)?

Thanks in advance,
Regards,
Richard

[Richard J Foster]

Peter,

Yes, I could understand problems if the references were not project
ones. In fact that is what I thought was going on at first, so I
removed the reference, then re-added it. The same thing happened!

I was even able to verify in the .csproj file that the reference is of
the form:
<Reference
Name = "ReferencedProj ect"
Project = "{3477EFD5-4BFE-4406-8C0D-605D00F7D5DB}"
Package = "{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}"
/>

The Visual Studio IDE still reports that it's going to use the file in
obj... and it does!

Granted, I can solve the problem by manually copying the file from the
bin folder. I just don't believe I should need to!

Just in case it has any bearing, I do not recall seeing this problem
prior to installing JetBrains' ReSharper 2.0 add-in for Visual Studio
2003. So far, I have not uninstalled ReSharper to see if the problem
goes away... but I wouldn't expect that to be the cause since it should
only be operating on the source files, not the output files.

Regards,
Richard

[Andreas Mueller]

Richard J Foster wrote:

Peter,

Yes, I could understand problems if the references were not project
ones. In fact that is what I thought was going on at first, so I
removed the reference, then re-added it. The same thing happened!

I was even able to verify in the .csproj file that the reference is of
the form:
<Reference
Name = "ReferencedProj ect"
Project = "{3477EFD5-4BFE-4406-8C0D-605D00F7D5DB}"
Package = "{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}"
/>

The Visual Studio IDE still reports that it's going to use the file in
obj... and it does!

Granted, I can solve the problem by manually copying the file from the
bin folder. I just don't believe I should need to!

Just in case it has any bearing, I do not recall seeing this problem
prior to installing JetBrains' ReSharper 2.0 add-in for Visual Studio
2003. So far, I have not uninstalled ReSharper to see if the problem
goes away... but I wouldn't expect that to be the cause since it should
only be operating on the source files, not the output files.

Regards,
Richard

Hi,

in VS2003 when you look at the properties of a project reference, it
always points to the debug path. For me this was always a fast way to
check if a special reference is a project reference.

From what I know, it also pulls the reference from there. Just try to
delete the bin and the obj directory form the referenced project. Only
the bin is deletable.

I also have Resharper 2.0 installed, and experienced no problems.

What I don't understand, is when signing is not part of your development
build, why the correctly signed assemblies are present at all? They
shouldn't during the development build. Maybe somebody checked in the
bin folder or inserted a build step do do the signing, ...

HTH,
Andy

[Mark Wilden]

"Richard J Foster" <ri************ @quixotetraffic .com> wrote in message
news:11******** **************@ h76g2000cwa.goo glegroups.com.. .

Just in case it has any bearing, I do not recall seeing this problem
prior to installing JetBrains' ReSharper 2.0 add-in for Visual Studio
2003. So far, I have not uninstalled ReSharper to see if the problem
goes away... but I wouldn't expect that to be the cause since it should
only be operating on the source files, not the output files.

I doubt ReSharper could be causing this. I follow their newsgroup and
haven't seen anything related to building.

///ark

[Richard J Foster]

Hi Andreas,

Andreas Mueller wrote:

What I don't understand, is when signing is not part of your development
build, why the correctly signed assemblies are present at all? They
shouldn't during the development build. Maybe somebody checked in the
bin folder or inserted a build step do do the signing, ...

I guess I was being unclear again.

The build process for distribution outside the department is handled
through a NAnt script (triggered from CruiseControl .NET on a
designated build machine). I can run the same script on my development
machine and, at least in the past, get the same output with the
exception of assembly version information. It was this I was doing when
I noticed the wierdness described in my original message. My first
thought was that the build script was broken, but then I found that I
could simulate the same operation in the Visual Studio IDE.

Perhaps it's an odd thing to expect... but I thought that if I manually
built *just* the referenced project, ran sn against the output to
complete the signing process, then manually built *just* the
referencing project it would also pick up the fully signed assembly
from the designated output folder for the referenced project. I guess
that's just such an obscure operation that almost nobody would ever
notice if it didn't work! :-)

BTW, I have not changed the version of Nant in use recently (even
though I am aware that RC4 was just released), so I do not believe that
is the problem.

Thanks for the suggestions though!
Regards,
Richard