Hello, I am working with 2 C# solutions right now, 1 is the main application we are creating (let's call it MainSolution.sln for now), the other is a unitTest solution (UnitTest.sln) created as a separate solution file, as the main solution consists of too many projects and compiling it takes a long time. It was created separately also because different groups of developers can work on the respective solutions they are tasked to do.
In the UnitTest solution, we create unit tests for the main solution classes, hence, for each project in the unitTest solution, I've added references to the respective main solution dlls. A typical full path of the Main solution's DLL is C:\MainApp\<foldername>\bin\Debug\<filename>.dll
I'm currently exploring ways to not 'hard code' the full path of the referenced dlls in the unit test projects. This is to solve the problem of developers saving the main app into a different folder other than 'C:\MainApp'. Currently, if they save the mainApp in some different physical directories, they will not be able to compile the unit tests as the mainApp DLL references' paths in the unitTest projects will still be C:\MainApp\...\...\bin\Debug\<filename>.dll. More importantly, we can also avoid having to manually change the DLL references for each unit test project (we might have more than unit test 50 projects and each project references 6-7 dlls) if say, one day we change the physical directory of the mainApp from C:\ to eg, D:\.
One way I thought of is to have each user set an environment variable, say %mainAppPath% to C:\MainApp the first time (and only once) before they work on any unit testing. Then when adding references to the projects in the unitTest solution, I'll use the environment variable instead of the full path. I.E. %mainAppPath%\..\..\bin\Debug\<filename>.dll instead of C:\MainApp\...\...\bin\Debug\<filename>.dll. I tried this method, but it doesn't work, because the environment variable automatically gets converted to the full directory path when I clicked 'OK' when I'm done with typing the path at the 'Add reference' dialog box. Am I missing out something
I am aware of the 'reference path' option to set up at each unit test project's properties. This will definitely be better than having to change each reference manually, but still doesn't automate the entire thing. If I have 50 unit test projects, I'll still need to update the reference path 50 times.
Does anyone know if it's possible to pass in arguments during the solution build and run time with a parameter (the physical directory) so the physical directory of the referenced dlls can be changed during compile and run time (based on the argument passed in) and not break the unit test solution Or is there an easier way to go around this problem
Thanks in advance and sorry if I asked a very easy to solve problem as i've just started picking up C#. Appreciate any kind of help!
Referenced DLLs - How to dynamically update the path of the reference dlls in another solution?
davidwii
Comment: You think solution for XP era, not for Vista and Longhorn. Look Visual Studio for Teams at:
http://msdn.microsoft.com/vstudio/teamsystem/default.aspx
for robust solution!
Team is power
Manoj Verma
Unfortunately I don't believe you can do what you want. However on a good note remember that references are really simply hints to the compiler and are relative to the project itself. It is generally a good idea to mandate the directory structure of your projects to ensure that problems like these don't occur. Of course most developers don't follow the same hierarchy so this sounds harder than it really is. The solution is to create a root directory from which all your solutions exist as subdirectories. The location of the root directory is irrelevant and can change based on the developer but the directories under the root are fixed and controlled by your CM server. For example:
<root>\MainSolution\...
<root>\UISolution\...
<root>\TestSolution\...
Now <root> can be anywhere a developer wants. However the subdirectories are fixed and can not change. Therefore they can use relative paths to reference each other as needed. In CM you would lay out the project as follows:
<parent CM project>/MainSolution/...
<parent CM project>/UISolution/...
<parent CM project>/TestSolution/...
Developers would set the working folder for <parent CM project> to whatever is appropriate for them. They would then get the entire project which would cause the appropriate subdirectories to be built. Of course you can add additional directories as needed. For example in my projects I have the following general layout:
<project>\Docs\...
<project>\Source\...
<project>\Tests\...
<project>\Build\...
<project>\Data\...
Michael Taylor - 7/28/06
ACKH
i had the same issue and i wrote a quick little add-in to help....you can download it here.
http://www.cybral.com/tools.aspx
Basically, you can add/replace/prepend/append reference paths to all selected projects in a solution.
Edit: I follow the basic suggestion the previous guy gave; however, I needed it because of a common set of assemblies shared across multiple projects that are not in the directory structure.
HTH,
-Mathew Nolton
NeTBaPb
You can use environment variables in your C# 2.0 project files. However, you have to manually add them to the project file with a text editor (i.e. outside of the IDE).
It seems that the IDE will load stuff like %MY_ENV_VAR%\foo from the project file and expand it as expected. It will also write the unexpanded string back to the project file when you save the project. The trick is that you can't edit the expanded text from the IDE or the IDE will write the expanded text back to the project file when it is saved.
This is major joke for anyone coming from C++. There should be full support for all of the environment variables that exist in C++. It just reinforces the view of C++ developers that C# is too limiting for serious use.
Why does Microsoft impose stupid limitations like this
pavel989
Hi TylerDurlin
It's not fare to say
> "It just reinforces the view of C++ developers that C# is too limiting for serious use."
because you first abuse IDE and secondly compare languages.
If you like, use what ever IDE you are used to be and state your builder for assembly.
With C# you are not limeted to Windows platform. You can embed your trusty C++ code with all nasty pointers to C# code using 'unsafe' attribute when appropriate! READ the C# language specification.
nice->to->be->here
soconne
Hi Michael,
Thanks for your suggestion.
I guess that will be the best way and of course is a good practice as well. =)
I will try that out. Appreciate your help!