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<CurrentReferences xmlns:d2p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays"> <d2p1:string>System</d2p1:string> <d2p1:string>System.Core</d2p1:string> <d2p1:string>ArtOfTest.WebAii, Version=2011.2.1506.0, Culture=neutral, PublicKeyToken=4fd5f65be123776c</d2p1:string> <d2p1:string>ArtOfTest.WebAii.Design, Version=2011.2.1506.0, Culture=neutral, PublicKeyToken=4fc62bbc3827ab1d</d2p1:string> <d2p1:string>Telerik.WebAii.Controls.Html, Version=2011.2.1506.0, Culture=neutral, PublicKeyToken=528163f3e645de45</d2p1:string> <d2p1:string>Telerik.WebAii.Controls.Xaml, Version=2011.2.1506.0, Culture=neutral, PublicKeyToken=528163f3e645de45</d2p1:string> <d2p1:string>Telerik.WebAii.Controls.Xaml.Wpf, Version=2011.2.1506.0, Culture=neutral, PublicKeyToken=528163f3e645de45</d2p1:string> <d2p1:string>System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</d2p1:string> : : : <d2p1:string>C:\Users\David Adams\Documents\Visual Studio 2010\Projects\vergeautomationtools\vergeautomationtools\bin\Debug\vergeautomationtools.dll</d2p1:string></CurrentReferences>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?
20 Answers, 1 is accepted
I received your project in my Dropbox and I'm starting to work on it. At the root I see two .sln files. I'm not sure which one is the correct one to work on:
vergeautomationtools.sln
VSuiteAutoWorking.sln
Can you clarify this for me?
Cody
the Telerik team
Test Studio Trainings
This is just a few notes on recommended code changes:
1) In autologin.cs you should change:
private void getSubDomain(){ string sBaseURL = ArtOfTest.WebAii.Core.Settings.Current.BaseUrl;To:
private void getSubDomain(){ string sBaseURL = ArtOfTest.WebAii.Core.Settings.Current.Web.BaseUrl;2) Same thing in public void TC256__New_Historical_Snapshot_CodedStep()
string subDomain = Manager.ActiveBrowser.Url.Substring(Settings.Current.Web.BaseUrl.IndexOf("//") + 2).ToLower();I'm studying the external DLL reference problem.
Kind regards,
Cody
the Telerik team
Test Studio Trainings
Rank 1
Rank 1
I apologize for the delay. I spent a lot of time carefully going through the entire project and all the tests. I made lots of tweaks some of which include:
- Deleting vsuiteautomation.csproj.user. It was causing an invalid reference error. Since it only contains user settings it is safe to delete.
- Rebuilt vsuiteautomation.csproj. It looked really messed up... why I cannot explain.
- Fixed references in the settings.aiis file
- Fixed all references in all projects
- Modified code in autologon.cs to take advantage of the TestContext.DeploymentDirectory for finding the Environments.xml file.
I'd like to meet with you online to review all the changes. I placed "InWork VSuiteAutoWorking.zip" in the dropbox folder that contains all the changes.
Cody
the Telerik team
Test Studio Trainings
Rank 1
Your times are EDT, right?
1. Please join my meeting, Monday, April 30, 2012 at 12:30 PM Central Daylight Time.
https://www2.gotomeeting.com/join/716588210
2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.
Dial +1 (619) 550-0003
Access Code: 716-588-210
Audio PIN: Shown after joining the meeting
Meeting ID: 716-588-210
GoToMeeting®
Online Meetings Made Easy™
Cody
the Telerik team
Test Studio Trainings
Rank 1
Ah, thanks for the reminder (I deal with too many customers to always remember which one is where). Same meeting invite updated for 1:30pm CDT. See you then!
All the best,Cody
the Telerik team
Test Studio Trainings
Rank 1
Hmmm... ok. Obviously unexpected. It builds locally just fine in Visual Studio? Can you attach the build output (as a file) showing the list of errors?
All the best,Cody
the Telerik team
Test Studio Trainings
Rank 1
Log is attached.
Ok, let's focus on just one of the compile errors. If we solve one we should be able to solve the rest of them the same way. Let's start with this one:
'vsuiteautomation.Pages' does not contain a definition for 'AddAuditRunPageFSRegressionAllQuestionTypes' and...
This element is defined in the test dev\CriticalQuestionAudit.tstest. Knowing this let's check the following:
1) Is that file checked in?
2) Does it exist in the build folder on the build machine?
3) Can you capture a copy of the Pages.g.cs file that is generated by the build machine?
4) Can you find this element defined in that Pages.g.cs file?
What's supposed to happen:
1) Get latest for the entire solution from source control
2) Regenerate the Pages.g.cs file using all of the elements from all of the tests contained in the project
3) Compile all of the source code files (the .cs files)
4) Run the tests
The error message indicates something is going wrong in step 1 or 2.
Cody
the Telerik team
Test Studio Trainings
Rank 1
dev\CriticalQuestionAudit.tstest is checked in.
dev\CriticalQuestionAudit.tstest exists in the build machine directory structure.
I deleted Pages.g.cs, rebuilt, and got the same results. Pages from the build server is attached.
Building locally, Pages does contain AddAuditRunPageFSRegressionAllQuestionTypes.
I think I discovered the problem. Looking inside the settings.aiis file is this section:
<ExcludedFiles> <Item Type="System.String">dev\Column Filters - Action Plans.tstest</Item> <Item Type="System.String">dev\CriticalQuestionAudit.tstest</Item> <Item Type="System.String">dev\removedocs.tstest</Item> <Item Type="System.String">dev\TC1210 - Create new FS survey audit with critical questions.tstest</Item> <Item Type="System.String">prod\core\CreateDocument.tstest</Item> <Item Type="System.String">prod\regression\Custom Views.tstest</Item> <Item Type="System.String">prod\regression\Enter Anonymous Entry.tstest</Item> <Item Type="System.String">prod\regression\FSasync.tstest</Item> <Item Type="System.String">prod\regression\Manage Vendors - ClaimantPlaintiff.tstest</Item> <Item Type="System.String">prod\regression\TC272 - Compliance - DocumentRecord - NewIssue.tstest</Item> <Item Type="System.String">prod\regression\TC316 - Content - Create new Content - Issues.tstest</Item> <Item Type="System.String">prod\regression\TC323 - Audit Record PageEdit - Edit Settings.tstest</Item> <Item Type="System.String">prod\regression\TC324 - Audit Data Entry Page - ViewRunsViewTotalRunsPrinter Friendly.tstest</Item> <Item Type="System.String">prod\regression\TC325 - Audit Record PageEditEdit Questions - Link questions to EPs.tstest</Item> <Item Type="System.String">prod\regression\TC326 - Audit Record Page - Enter Aggregate Data.tstest</Item> <Item Type="System.String">prod\regression\TC329 - Users - Edit User Demographics.tstest</Item> <Item Type="System.String">prod\regression\TC330 - Users - Search User by Name.tstest</Item> <Item Type="System.String">prod\regression\TC332 - Users - Change rows per page - System & Single Org.tstest</Item> <Item Type="System.String">prod\regression\TC333 - Users - Run Individual User Activity Report.tstest</Item> <Item Type="System.String">prod\regression\TC335 - Users - Modify Standards Access.tstest</Item> <Item Type="System.String">prod\regression\TC338 - Users - Edit User Security Group.tstest</Item> <Item Type="System.String">prod\regression\TC339 - Users - Edit Expiration Period.tstest</Item> <Item Type="System.String">prod\regression\TC344 - Reports - Question Reports - Create Question Report.tstest</Item> <Item Type="System.String">prod\regression\TC460 - Reports - Run Organization Activity Report.tstest</Item> <Item Type="System.String">prod\regression\verify FS entry change - prodsupport.tstest</Item> <Item Type="System.String">prod\regression\VerifyADLogin.tstest</Item> <Item Type="System.String">prod\regression\opsource\Audit Wizard Creation - ChiTech.tstest</Item> <Item Type="System.String">prod\regression\opsource\Audit Wizard Creation.tstest</Item> <Item Type="System.String">prod\regression\opsource\CheckK2.tstest</Item> <Item Type="System.String">prod\regression\opsource\DeleteAutomationAudits - vs1.tstest</Item> <Item Type="System.String">prod\regression\opsource\DeleteAutomationReports.tstest</Item> <Item Type="System.String">prod\regression\opsource\Feedback Server Audit Entry - ChiTech.tstest</Item> <Item Type="System.String">prod\regression\opsource\Feedback Server Audit Entry.tstest</Item> <Item Type="System.String">prod\regression\opsource\Login - VStandard.tstest</Item> <Item Type="System.String">prod\regression\opsource\Login - VStandardAdmin.tstest</Item> <Item Type="System.String">prod\regression\opsource\Reports - ChiTech.tstest</Item> <Item Type="System.String">prod\regression\opsource\Reports.tstest</Item> <Item Type="System.String">prod\regression\opsource\Test Compliance Scoring - ChiTech.tstest</Item> <Item Type="System.String">prod\regression\opsource\Test Compliance Scoring.tstest</Item> <Item Type="System.String">prod\test stubs\UserLookup.tstest</Item> <Item Type="System.String">common\login - tuser1.tstest</Item> <Item Type="System.String">dev\telerikdemo.tstest</Item></ExcludedFiles>Notice that dev\CriticalQuestionAudit.tstest is included in this list. This means Test Studio will not include it while generating the Pages.g.cs file. Now I don't know why it's working locally.
So the solution is to do one of two things:
1) If dev\CriticalQuestionAudit.tstest is not needed, just delete it.
2) If it is needed, removed it from the ExcludedFiles section of Settings.aiis All the best,
Cody
the Telerik team
Test Studio Trainings
Rank 1
I made the changes to Settings.aiis. I have no idea how those exclusions got there. I did not put them in.
I did get the automation in the build environment to try to execute but when starting execution, I am seeing the hard-coded path "E:\Users\Dad\Desktop\InWork VSuiteAutoWorking\vergeautomationtools\bin\Debug\vergeautomationtools.dll" not being found by mstest.exe. It appears the hard-coded paths in a tstest file are not ignored.
I am ready (after 12:00 CT) for another phone call when you are ready.
You got it.
1. Please join my meeting, Tuesday, May 01, 2012 at 1:00 PM Central Daylight Time.
https://www2.gotomeeting.com/join/275798138
2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.
Dial +1 (267) 507-0008
Access Code: 275-798-138
Audio PIN: Shown after joining the meeting
Meeting ID: 275-798-138
GoToMeeting®
Online Meetings Made Easy™
Cody
the Telerik team
Test Studio Trainings
I just made an interesting discovery. If you literally delete the entire <CurrentReferences section, then close the Visual Studio project (or do this outside of Visual Studio) it appears that Test Studio will not put anything back in it.
The only time it does put something back in (in the testing I've been doing) is if you open the project in Visual Studio, then open the test in an XML editor, make a change, then open the test again in the Test Studio editor and make another change, the CurrentReferences will be reset. This is because it's writing back to disk what was in memory. By changing then closing the project, it won't try to save the in-memory cached version.
Please give this a try and let me know how it goes.
Cody
the Telerik team
Test Studio Trainings
Rank 1
We made significant changes to how we're storing/defining external DLL references in a Test Studio project. These changes are included in our latest release, 2012.1.528. Please give this version a try and let us know if you have further problems.
Regards,Cody
the Telerik team
Test Studio Trainings