Project References (repost with fixed msdn alias)

[Adrian]

We've come across a problem using source control when dealing with project
references and are looking to find out what the proper way of dealing with
this is.

When we add a reference to an assembly (in this case to
ajaxcontroltoolkit.dll), it seems to put the full path to the dll in the
project reference. Unfortunately as this is under the program files area,
it causes problems because some developers don't have a program files area,
they have a program files (x86) area instead, so the project doesn't find
the assembly when they download the project it from source control.

How should this be done to avoid this kind of problem?

TIA.
--
Adrian

(Sorry I had to duplicate post, but MS insisted that my MSDN posting alias
wasn't recognised even though I've used it before, so I've had to update
that and repost using the new alias)

 

[sloan]

You have to make references to the files/paths ~~~relative~~~. All relative
all the time.

Here are directories:

\DotNet\
\DotNet\v20\
\DotNet\v20\Assemblies\
\DotNet\v20\Assemblies\Applications\
\DotNet\v20\Assemblies\Framework\
\DotNet\v20\Assemblies\Framework\Beta\
\DotNet\v20\Assemblies\Framework\Release\
\DotNet\v20\Assemblies\ThirdParty\
\DotNet\v20\Assemblies\ThirdParty\Release\

================
\DotNet\v20\Source\
\DotNet\v20\Source\Applications\
\DotNet\v20\Source\Framework\

==examples, not to actually include
\DotNet\v20\Source\Applications\SodaManager\
\DotNet\v20\Source\Framework\MyCompany.DataHelpers\


That is our company's structure. We have "v11" and "v35" as well.

Basically, \DotNet\v20\Assemblies\ is the root for compiled assemblies.
\DotNet\v20\Assemblies\ThirdParty\Release\ajaxcontroltoolkit.dll
would be where we could put that dll.

Let's say your application is
\DotNet\v20\Source\Applications\SodaManager\SodaManager.sln
\DotNet\v20\Source\Applications\SodaManager\PresentationLayer\SodaManagerPresentationLayer.csproj
in that (cs)project, you would reference ajaxcontroltoolkit.dll by using the
"browse for"

Now your reference will be RELATIVE as
...\..\..\..\Assemblies\ThirdParty\Release\ajaxcontroltoolkit.dll


You can pick relative or absolute, but those are your choices.


Get all developers on the same page. Pick a standard, live by it.


Now, different workers can have slightly different setup:

one person:
C:\Work\DotNet\

and another person:
D:\WorkStuff\DotNet\


But at the DotNet level and beyond, it HAS TO BE THE SAME.

 

[sloan]

FYI: Here is my references section from one of my csproj files (opened in
notepad)


<ItemGroup>
<Reference Include="MyCompany.DataHelper, Version=2.0.0.0,
Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\..\..\Assemblies\Framework\Release\MyCompany.DataHelper.dll</HintPath>
</Reference>
<Reference Include="Microsoft.Practices.EnterpriseLibrary.Common,
Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\..\..\Assemblies\Framework\Release\Microsoft.Practices.EnterpriseLibrary.Common.dll</HintPath>
</Reference>
<Reference Include="Microsoft.Practices.EnterpriseLibrary.Data,
Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\..\..\Assemblies\Framework\Release\Microsoft.Practices.EnterpriseLibrary.Data.dll</HintPath>
</Reference>
<Reference Include="Microsoft.Practices.ObjectBuilder,
Version=1.0.51205.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\..\..\Assemblies\Framework\Release\Microsoft.Practices.ObjectBuilder.dll</HintPath>
</Reference>
<Reference Include="System" />
<Reference Include="System.Data" />
<Reference Include="System.Transactions" />
<Reference Include="System.Xml" />
</ItemGroup>


Obviously, I'm using the Microsoft.Practices
(Microsoft.Practices.EnterpriseLibrary) framework, among some others.
But the paths are all relative. No absolutes.

 

[Colbert Zhou [MSFT]]

Hello Adrian,

Thanks for your posting! I can see the mentioned problem.

Actually, there are two scenarios when we reference an assembly in our
project. These two scenarios cause different modifications into the .csproj
file.

1. If we reference an assembly from some IDE known places. It will only add
the assembly general information into the project file without its
location. For example, if we navigate to .NET tab in the Add Reference
dialog and choose Microsoft.VisualStudio.Tools.Applications.Runtime.9.0,
click OK. The following line will be added into the .csproj file

<Reference
Include="Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0,
Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a,
processorArchitecture=MSIL" />

2. If we reference an assembly from IDE NOT known places. For example, we
navigate to Browse tab in the Add Reference dialog, and go to C:\Program
Files\, choose AjaxControlToolkit, and click OK. Then, the referenced
assembly will appear in the Visual Studio with location information,

<Reference Include="AjaxControlToolkit, Version=3.0.20820.16598,
Culture=neutral, PublicKeyToken=28f01b0e84b6d53e,
processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\..\..\..\..\..\..\Program
Files\AjaxControlToolkit.dll</HintPath>
</Reference>

All the location information is hard written. So the Program Files folder
will not be redirected to Program Files(x86) folder in x64 system machine.
Therefore, the mentioned issue occurs.

So our solution is putting the AjaxControlToolkit assembly in the IDE known
places. So the .csproj file does not keep the location information. It
leaves the job to IDE to find the right place to get that assembly. The
most famous IDE known folder for assemblies is,

C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies

In the x64 machine, we need to put the AjaxControlToolkit into
C:\Program Files(x86)\Microsoft Visual Studio
9.0\Common7\IDE\PublicAssemblies

After check out the project from the VSS, IDE reads the .csproj file and
will search the AjaxControlToolkit.dll in C:\Program Files(x86)\Microsoft
Visual Studio 9.0\Common7\IDE\PublicAssemblies by default.

Please let me know if you have any future questions on this. Have a nice
day!


Best regards,
Colbert Zhou ([email protected], remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Adrian]

Thanks guys, I'll take a look, hopefully people won't complain too much