I am having some serious issue when migrating Coded UI test from VS2010 to VS2012. The issue is related to assembly reference. I try to reference the new 11.0 version CodedUI assemblies, but the system keeps looking for the old 10.0 version when VS2012 tries to find all the cases and list in the Test Viewer. Such as:
'Microsoft.VisualStudio.TestTools.UITest.Extension, Version=10.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
I found this MSDN link: http://msdn.microsoft.com/en-us/library/tfs/hh506981(v=vs.110).aspx
It mentions some issue related to assemlby reference. But I don't understand the following quotation:
In Visual Studio 2010, references were added inside a ‘Choose’
statement in the csproj file. In Visual Studio 2012, we are using
a Feedback targets file to include Coded UI Test Assembly references.
What is a Feedback targets file??
I've covered your problem with the answer in this blog post.
You need to open your proj file and check for the logic that has been added to reference properly the version 11.0.0.0 of the testing tools assemblies.
I presume the feedback targets file is the imported msbuild file in the VS 2012 folder for msbuild targets. It is an implementation detail, all you need is to focus in upgrading your project file according to what the "repair" wizard is supposed to do, I give precise steps in my post.
Regards and good luck (if I'm not too late)
Related
There is a bug in the WiX plugin for Visual Studio where file locks on referenced DLLs are not properly released. Therefore, you have to restart Visual Studio every time you want to recompile a custom extension DLL or any assembly referenced by it.
This is a known bug, but the issue was closed because there seems to be a solution / workaround:
You can force the WiX .exes to run out-of-process to avoid the lock
MSBuild has.
I don't understand how to achieve this. I checked...
the properties of my WiX setup project
the properties of the extension assembly (C# class library)
all Visual Studio settings
the available command line arguments of candle.exe
...but did not find anything. What am I missing? How do I apply this workaround?
I'm using WiX 3.10 and Visual Studio 2013.
The example that I've seen several times around the web is to add <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> to the Wix Installer's project file within a property group. Unfortunately, documentation of this feature has thus far eluded me.
I've been searching all morning for an answer online to this and I have tried a lot of the suggestions though all solutions seem to be for visual studio 2010 and I am running 2013 premium edition, I can't see anyone with the same problem.
I have premium VS 2013, I installed SpecFlow v1.9 through the extension manager and added the SpecFlow nuget package. I have created a CodedUI test project and added a feature file, some recorded codedui steps and a stepdef file. Nothing is complaining and it all looks like it should work. I have added :
<unitTestProvider name="MsTest"/>
to my App.config so I can run it from the test explorer in visual studio. I eventually want to run the tests via MTM but I will deal with that when I get this to work!
I have built and it is all happy so I go to test explorer and I can see my test so I right click, run the test. It fails with the following error, it does get to my Given step when I debug and falls over trying to open my application.
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.VisualStudio.TestTools.UITest.WindowsStoreUtility, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
I can not find the reference above when I have looked to add it to my project references, there is a similar one but it breaks some of my other references when I add it. I also had a look at my registry files and the path it is referring to does not exist for me to edit it. From what I have read codedui doesn't work nicely with specflow without a dll file. All references to this fix seem to be for vs 2010 and require that I copy a dll to my specflow source folder. I installed specflow from visual studio so I don't have a program files folder for it so I came to a bit of a sticking point with that solution.
Does anyone have specflow working with visual studio 2013 and a codedui test project? Am I missing a set up step? Or is this genuinely to do with my registry files / references. The error is confusing as I don't see why it is trying to find that reference especially when I can't find that reference anywhere when I try to find it manually. I'd be interested to know if you have had this error and managed to resolve it or if you could explain your set up steps so I can check I did not miss anything.
Thanks!
I believe you might be missing references to some of the required dlls. I just finished testing a test created using a Specflow, codedUI test project on my MS Visual Studio 2013 ultimate and it worked just fine.
Here are the steps which I followed:
Created a class library project.
Added reference to Specflow 1.9 from Extensions and Updates.
Added reference to Specflow CodedUI Attribute Generator (Install-Package SpecFlow.CodedUI -Version 1.0.0.23).
Added references to required libraries required for CodedUI and Test Tools to the project. See below the references I added.
Microsoft.VisualStudio.QualityTools.CodedUITestFramework
Microsoft.VisualStudio.QualityTools.UnitTestFramework
Microsoft.VisualStudio.TestTools.UITest.Common
Microsoft.VisualStudio.TestTools.UITest.Extension
Microsoft.VisualStudio.TestTools.UITest.ExtensionUtilities
Microsoft.VisualStudio.TestTools.UITesting
Added a separate CodedUI project to solution and added references of this project to the class library project.
Create a new Specflow feature file with some test and create step for it in step definition and reference to the function you created or recorded in the CodedUI project in the step definition.
Run the Specflow test from Test Explorer. It should work fine.
Note: The above steps should work just fine if you will create CodedUI project instead of a Class library project.
Mark the test class with the CodedUITest attribute.
I had this exact error message even though I had all the .dll's referenced correctly.
The solution for me was to regenerate the feature files.
(right click project and select "regenerate feature files")
Leaving this answer in case it helps someone in future.
I came across the same issue today, not with specflow but 2013 build controller and agent and codedui tests.
The solution was to install VS2013 Update 5 https://www.visualstudio.com/downloads/download-visual-studio-vs
I had same problem, found the following solution works well:
http://blog.majcica.com/2015/05/07/getting-started-with-specflow-and-codedui/
When I try to register a visual studio package using regpkg in Visual Studio 11 RC, I get the following error:
regpkg.exe /root:Software\Microsoft\VisualStudio\11.0 /codebase myvspackage.dll
Could not load file or assembly 'Microsoft.VisualStudio.Shell, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The
system cannot find the file specified.
This worked fine with previous versions of Visual Studio. I'm working in a clean virtual machine that only has Visual Studio 2012 RC.
I've been surfing the web looking for a solution with no success.
If I just copy the Microsoft.VisualStudio.Shell.dll in my app location it works fine, but this dll is not redistributable, so... what's the right way of registering a package in Visual Studio 11?
Thanks in advance for your help,
Luis
I'll assume you also posted this to the MSDN forums since a question with identical text was posted there which I answered yesterday.
http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/96556cd4-44dd-4e01-8198-b83a66c6df26
In short it sounds like you have an explicit reference to v2 of Microsoft.VisualStudio.Shell.dll, James is incorrect in saying you aren't supposed to use this, this is simply MPF from 2005. Referencing it is perfectly fine. If you have an explicit version in the reference in the project file try dropping it, if not try adding the binding redirect mentioned in my MSDN forum post.
I have started a mail with the SDK team about this issue though I don't know if they will be taking any changes this close to release. Also, as an FYI, since Shell.dll is from 2005, it is nearing the end of its supported life, we generally support three versions of previous VS releases.
On release of 2012 the support will be 2008,2010, 2012. I suspect in the next release (after 2012) we may stop including Shell.dll (the 2005 version) entirely in the shipped product. Unless you need to run downlevel on say 2005 I would update the reference to one of the newer shell assemblies (like 9.0, 10.0 or 11.0)
Here's a puzzler - something that doesn't work that I assumed would (no surprise there).
We have a library project that is referenced in a few other desktop app projects. The library project is written in VS 2005 (.NET 2.0).
My problem is that some of our apps still live in VS 2005 for the time being (for various reason). I can't seem to reference this library project in VS 2010 without it demanding that I upgrade it to .NET 4, which if I do, then breaks my ability to include it as a reference in my VS 2005 projects.
This type of thing fries my brain. Is there any way I can make this work?
Hmm, that doesn't make a lot of sense. You don't reference a 'library project', you reference the DLL that it produces. Project + Add Reference, Browse tab. There's no known problem with that, within a 95% accuracy guess, mixed mode assemblies have a few hairs.
If you actually try to load a vs2005 project into a vs2010 solution, then yes, it's going to try to convert the project file. And that turns vs2005 catatonic, it doesn't have the time machine to guess what a vs2010 project looks like. Just making a copy of the project directory solves that problem.
Can you change the .NET version back to 3.5 or 2.0 in VS.NET 2010 after it revises the project version to .NET 4.0?
Use a file reference to the built dll, rather than a project reference.
You may also find you need to add an extra bit of compatible-framework info to your manifest file to tell .net to allow your .exe to use .net 4 and .net 2 assemblies alongside each other - if it's not there you'll just get an error on startup. (Sorry, I can't remember the exact details and I'm not at my work machine right now to be able to find them - but if you have problems at runtime, the error message should lead you to the exact solution you need)
Correction: I was thinking of this 'useLegacy' startup setting, which you may need to add to your app.config if you want to use a mixture of .net 2.0 and .net 4.0 assemblies in your application:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
On option, that is a complete PITA, but should work is:
Create a new project file in 2010 that includes everything the 2005 project file has. Just call it MyProject2010.csproj or whatever.
Then, add this project to your 2010 solution.
I've loaded a WPF project initially created in Visual Studio 2008 into Visual Studio 2010. The conversion process goes smoothly, but on certain XAML files the VS2010 designer throws several errors related to project references, including this one:
System.Reflection.Adds.UnresolvedAssemblyException
Type universe cannot resolve assembly: GalaSoft.MvvmLight, Version=3.0.0.31869, Culture=neutral, PublicKeyToken=3e875cdb3903c512.
This assembly reference works just fine in the Expression Blend 4 designer, but not in VS2010.
I can build and run the solution successfully.
My solution targets the .Net Framework 3.5 SP1.
I can't quite tell if you're having the same problem I had or not, but I was getting that type universe error all the time with the Ninject .dll. I solved it by "Unblocking" the zip file before extracting it. I think this only affects Vista and Win 7 dev machines but it's worth a try. I posted a blog entry last week with details on the error and the solution. Scroll down to the "Foiled by a Blockhead" section.
Check which version of the MVVM Light assemblies you are referencing.
When you install the MVVM Light Toolkit binaries, you get separate WPF 3.5 and WPF 4 versions. You can find the WPF 4 assemblies (assuming default install location) in
c:\Program Files\Laurent Bugnion (GalaSoft)\Mvvm Light Toolkit\Binaries\WPF4
I found a workaround, but I'm not happy with it. If I change the target framework setting for the project from ".NET Framework 3.5" to ".NET Framework 4 Client Profile" the designer works just fine. But I'd rather not change my target framework just to get designer support!