We are using VSTS to perform Continuous Integration utilizing a build template that was created to deploy a website to a Dev machine.
This worked fine but then we wanted to add in CodedUI tests to the build template in order to run the tests as part of the build step.
So I added a Visual Studio Test step to the build and added in the test by referencing the test plan and test suite it was associated with.
I made sure the codedUI project was built within the same solution as the website in order to make sure the binaries were built with it.
The problem I'm getting is that when the build runs it brings back errors stating that it is missing the relevant references for the code to work such as:
QualityTools.CodedUITestFramework
QualityTools.Common
TestTools.UITesting
etc.
However these reference are included in the project and "Copy Local" is set to true.
Does anyone have any idea what could be going wrong?
UPDATE
New error received:
MSTestAdapter failed to discover tests in class
'Email_Regression.CodedUITest1' of assembly
'C:\agent_work\4\s\Microservices\Email\Email
Regression\obj\Release\Email Regression.dll'. Reason Could not load
file or assembly
'Microsoft.VisualStudio.QualityTools.CodedUITestFramework,
Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified..
No test is available in C:\agent_work\4\s\Microservices\Email\Email
Regression\bin\Release\Email Regression.dll
C:\agent_work\4\s\Microservices\Email\Email
Regression\obj\Release\Email Regression.dll. Make sure that test
discoverer & executors are registered and platform & framework version
settings are appropriate and try again.
After talking to the Microsoft help team it appears that you need to have Visual Studio Enterprise edition installed on the machine you wish to run the codedUI tests on.
Update
After discussions with Microsoft and highlighting this being a rubbish solution they are now going to deliver the dll's as part of the new vsTestPlatform installer. I'm not saying this is down to my complaints, just coincidental timing.
I have created a project using specflow, so I have a new feature file saved as a class library project, when I try and run the project I get the error: 'A project with an Output Type of Class Library cannot be started directly. In order to debug this project, add an executable project to this solution which references the library project. Set the executable project as the startup project'
I think it's an error with the way I have added the n-unit and specflow references to the project. I have noticed I could install specflow via NuGet packages or extensions and updates. So what the difference between adding packages in these two ways?
They are two different things.
the Specflow extension extends the visual studio ide to support specflow. Specifically:
it adds syntax highlighting support for gherkin syntax
it allows the tests to be generated from .feature files
it adds the file templates to the file types so you can add new feature files/step bindings
it adds the additional context menu options to allow steps to be generated and the navigation between steps in the feature file and steps in the code.
it allows integration with the visual studio unit test windows
and probably a few more things that I've neglected to mention. Without this writing specflow tests in visual studio would be more difficult and the generation of the unit test cases themselves would be not be done.
the nuget package allows an individual project to use specflow. This adds the necessary references to the project so that you can consume the types which specflow uses. without these being referenced the projects which try and use specflow would not compile.
As for your issue, this is not related to specflow in any way. A project which builds a dll cannot be started, it needs something to be hosted in in order to be used any project which is a library will give this error if you set it as the startup project regardless of if you use specflow or not.
Recently upgraded to VS 2010 from 2008, the previously built solutions are throwing the following error.
Error 14 Encountered multiple versions of the assembly with GUID 'a5851ea0-2f9a-40b2-a73a-cd7db32f09c5'. Try pre-importing one of these assemblies
I tried re-installing VS 2010 and it didnot help. Any ideas?
Is it the VS 2010 application itself crashing, or does it not like your solution? Can you open VS 2010 by itself? If so, it sounds like it doesn't like some of your references in one or more of your projects. Check the project references. If that doesn't work, start removing projects until you find the offending one.
This may happen, if you copy-paste-renamed a project file to re-use its settings but didn't changed the project GUID of it. Also could be a project migration error, anyway you will have to manually edit the project file and remove the duplicate references if the project fails to load because of the error.
I had the same issue when migrating 2008 -> 2013.
It was caused that we use same linked AssemblyInfo.cs for all projects in solution.
And only for the assembly that used some COM objects (MSMQ) it seems that it starts looking on referenced assemblies GUID and two of them from our solution...
So when I provide individual AssemblyInfo.cs for projects with unique GUIDs it start working.
Hope this info will helpful.
Try to remove the references to the debug folder.
In Visual Studio right click on Project
Select Properties
Select the references tab.
Check to see if any of the references are from the obj\Debug folder and remove them.
See similar question here.
I have a quick question....building a VS 2010 SharePoint project and I am referencing a custom assembly. I can reference this assembly in my code and it works fine to write code and all. When I deploy the project to SharePoint my Feature Activation code will not run because the custom assembly does not get deployed with the project.
I have set Copy Local to TRUE on the referenced assembly. Am I missing something?
Thanks
When you Create SharePoint Project in Visual Studio 2010, you will see a Item called Package in it.Click open it and bottom left corner click on Advanced, you will see an option to add additional assemblies , add as many you want > all assemblies you select here will get deployed as a Part of SHarePoint Package you create.
Not sure if this is what you're looking for, but you can use ilmerge.exe to bundle satellite managed assemblies into your executable, making it portable and more easily deployed. I use it all the time, it works great.
You can set up a build event in VS2010 to do this automatically whenever you build, too, though it can be a bit slow (I have it set as a Release-only build event for this reason).
Why do I get the following error when building a setup project?
An error occurred while validating. HRESULT = '80004005'
One project in solution had ToolsVersion="4.0" (in .csproj file), changed it to ToolsVersion="3.5" and setup project builds fine.
Both of the reasons I found are already in other answers, but they are in separate answers and not fully explained. So, hopefully this will combine the possibilities and give good means of debugging each. :)
Common Reason
My problem was not a dependency error. However, that does seem to be the common reason. So, basically, you need to check your MSI file and make sure that all dependencies are still valid. Probably the best blog response on how you can easily resolve this if it is a dependency issue is An error occurred while validating. HRESULT = '80004005'.
Extract from blog:
Follow steps below to troubleshoot.
If you have multiple project outputs in your solution, identify the project that is giving the problem. You can do that by removing one project at a time from the Setup Project(S) until error goes away.
Once project is identified, identify the reference that could be giving the problem.
Check if the project(A) is referencing to a project that has been removed from solution. - Remove such references if any.
Check if the Project(A) is referencing to a project that was moved to a diffenrent physical location after it was added as a reference. - Remove and add such references.
Rebuild setup project after fixing the reference accordingly to see if error goes away.
Alternative Reason
My problem had to do with Visual Studio versioning, however. So, if your dependencies are valid and you still are getting this problem, then you resolve this if it is a problem with VS2010 .
Basically, if you run MSBuild and see this warning:
Project file contains ToolsVersion="4.0", which is not supported by
this version of MSBuild. Treating the project as if it had
ToolsVersion="3.5"
Then the problem is Visual Studio versioning. This means that one project was opened or created in Visual Studio 2010 and then saved or added to an existing 3.5 solution. I simply searched all files in my project for ToolsVersion="4.0" and found the offending .csproj file, opened it in a text editor and manually changed the 4.0 to a 3.5.
This error is related to a dependency error. I removed all references to my primary output project and added them again. It now compiles OK!
I ran up against this issue today. The solution in my case? Restart Visual Studio 2008.
In my case my solution (VS2008) had a project that was also referenced from another solution (VS2010). In the VS2010 solution I had upgraded the project to .NET 4.0. When I later realized the project was also used in another solution I downgraded it to .NET 3.5. For some reason everything seemed to be changed correctly in the csproj file except one place which is mentioned here: Error in setup project HRESULT = '80004005'
I know this is already solved somewhere else but I wanted to shed some light on this from another problem angle.
While simply removing and re-adding the project dependencies will work in many cases, it is important to note that:
The error message "An error occurred while validating. HRESULT=80004005."
usually happens when project is referenced to the other project which is
not added into the currect [sic] solution. Setup project only supports
dependency projects within same solution.1
I have spent enormous time on this one myself, though none of the above worked. But I have found another solution with a registry hack, you need to add a new DWORD (EnableOutOfProcBuild) value of (0) to HKCU\SOFTWARE\Microsoft\VisualStudio\14.0_Config\MSBuild\EnableOutOfProcBuild
Note: this is for Visual Studio 2015
In my case I had installed Visual Studio 2010 alongside Visual Studio 2008. My setup project, when opened in Visual Studio 2008 gave the same error, but was OK in Visual Studio 2010.
If copied to another machine that did not have Visual Studio 2010, but did have Visual Studio 2008, then it would compile.
I installed Visual Studio 2010 and converted the solutions to that version. Because of performance issues I changed my solutions back to Visual Studio 2008. Everything was better now but I got an error when I tried to compile the setup project. I realized that I had a Visual Studio 2010 Test Project in my solution so all I had to do was unload the Test Project and Build the setup project again.
Summary: unload any Visual Studio 2010 project in solution.
I hope it helps.
I know this is kinda old news, but my particular issue and solution are not specifically stated here (as far as I can tell - if I missed it, I apologize).
I had same problem. It would not compile my project, but had no errors. All I could see was "Build Failed". I opened up the "Output" file (Click View--> Output on menu), and it told me exactly which reference (in my case a .dll) was causing the problem.
I deleted and recreated the reference and it changed the reference name from Microsoft.Office.Core (which was appearently only a 32 bit version) to "OFFICE". Then everything worked great. -- Make sure to make a note of the path to the file you are referencing in the properties window... My new path was exactly the same, but the reference name changed anyway.... still scratching my head on that one...
So the moral of the story is... When you get no errors and your build fails, check the "Output" tab and it might help.
I read this answer from another post on Stack Overflow, and it has worked for me.
Open your setup project file (.vdproj) in Notepad (or any other text editor). Delete these lines at a beginning of the .vdproj file:
"SccProjectName" = "8:"
"SccLocalPath" = "8:"
"SccAuxPath" = "8:"
"SccProvider" = "8:"
Build again - the error is gone. That error didn't stop me from deploying, building, debugging (or anyting) my project; it just annoyed me. And it came on even if I set all projects to be build in a current configuration and the setup project not to.