I am trying to use a reference to a third-party dll in my project and am not having any luck.
As background, the "third-party" dll is actually something I built but I want to use the dll as a common method library. For example, this dll allows me to authenticate a user for my web application without having to enter username and password on the log in page. I want to reference the dll as if it were a common library.
I am using the Test Studio Visual Studio plug-in, NOT the stand alone version.
I was able to make the reference easy enough and my runs perfectly in my local dev environment. When I move my code to my build (in this case CruiseControl) environment, the referred dll cannot b
e found. The .tstest file is looking for the dll in the project folder with the same directory structure as my local dev environment (e.g. c:\users\...). We put all of our CruiseControl files on an E: drive in the build environment. So the third-party dll location on the build environment is NEVER "c:\users..." but rather "e:\cruisecontrol\automation...".
All of our other projects, by the way, do call other referred perfectly fine.
I have tried a number of steps to get around this issue but need more help. I have tried:
1. Removing the references from the .tstest file. I opened the offending .tstest file in an XML view and removed the "hard-coded" lines from the CurrentReferences section. For example, I removed:
<d2p1:string>C:\Users\David Adams\Documents\Visual Studio 2010\Projects\vergeautomationtools\vergeautomationtools\bin\Debug\vergeautomationtools.dll</d2p1:string>
from
I also removed numerous, similar references from Settings.aiis. Settings.aiis appears to keep old versions of references around for whatever reason even after I have explicitly removed the reference to a dll.
Something I have noticed is that Visual Studio (or Telerik or whomever) is adding the bad and old versions of the dll references when editing the .tstest file using the "Run To Here" functionality. I use that feature A LOT and now need to edit the XML every time I use the feature. PLEASE NOTE: THE REFERENCES ARE NOT RE-ADDED EVERY TIME "RUN TO HERE" IS USED MAKING IDENTIFICATION OF THE ISSUE THAT MUCH MORE DIFFICULT.
2. I have added a hard-coded reference in my build environment to this dll. I created the path and file "
C:\Users\David Adams\Documents\Visual Studio 2010\Projects\vergeautomationtools\vergeautomationtools\bin\Debug\vergeautomationtools.dll"
on the build server. I have come to find that there are security issues with that and that path still cannot be found when executing my test on the build server.
I find this to be a very weak solution to what should not even be an issue.
3. I have changed the entire structure of my solution to include the dll project and my automation project together and make a project reference. Visual Studio still makes an absolute-path reference to the dll so there is, in essence, no difference than making a regular file reference.
4. I have tried to strongly-name the third-party dll and added it to the GAC. Even when adding from the GAC
the directory path that appears in Visual Studio is "c:\users...". This is another weak solution.
5. I created c:\automationdlls and added my dll to this folder. To avoid the c:\user.. security issue I created c:\automationdlls on both my local dev environment and the cruisecontrol environment. When adding a reference to the dll, the directory path that appears in Visual Studio is "c:\users...". Back to square 1.
Of the hundreds of Telerik customers reading these forums, I have to believe that one of you are referencing third-party dlls and building that code in a cruisecontrol environment that is not running off the c: volume. Can anyone assist on this?