Error when running MSpec - how do I troubleshoot? - visual-studio-2010

I am following this guide to installing and using MSpec, but at the step where he runs MSpec for the first time, I get the following error:
Could not load file or assembly 'file:///[...]\Nehemiah\Nehemiah.Specs\bin\Debug\Nehemiah.Specs.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
I have - to my knowledge - done everything more or less exactly like he did up to this step, except where differences arise because he's using VS2008 and I'm using VS2010, and everything has worked so far. The project Nehemijah.Specs (and the entire solution) builds without problem, both in Visual Studio and on my build server, and I can't find anything useful in Event Viewer (although I might not be looking in the right place here...)
What to do?

It appears you're compiling the Nehemiah.Specs.dll assembly against the .NET Framework 4. In order to run your specifications you need the .NET 4 build of MSpec which contains a console runner (mspec.exe) that is suitable for this version of the framework. You can find the a zip file containing the build on CodeBetter's CI server.
Other possibilities of running .NET 4 spec assemblies are
TestDriven.Net 3.0
ReSharper 5.0
Runners for both tools are also included in the distribution.

Related

How to resolve Lock file error? "...contains msbuild projects but there is no export file"

I am running visual studio Community 2015 Update 3. I have a solution that has been compiling fine but is now generating an error when I try to compile it. The error is
Lock file Microsoft.DotNet.ProjectModel.Graph.LockFile contains msbuild projects but there is no export file
This error is displayed in the Error List window when I compile the solution and the error list indicates that it relates to a project in the solution which is an .Net Core Library that houses my xUnit tests.
The error information indicates that the error is on line 262 of C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets
Screenshot of that location selected below:
The solution contains:
____Asp.Net Core project targeting net461
____Windows Library Project targeting .Net Framework
____ A 2nd Windows Library Project targeting .Net Framework 4.61
____A .Net Core Libary Project targeting net461 (used holding XUnit Tests)
If I try to compile each project individually, they all compile fine except for the project holding the xUnit Tests that generates this error.
The Big Question
So what does "Lock file Microsoft.DotNet.ProjectModel.Graph.LockFile contains msbuild projects but there is no export file" mean? And how can I fix it?
Posting how I got past this error in case it helps others. Ultimately this issue was solved by removing all the projects from the solution, adding them back one by one and then reestablishing the project references. I would attribute the root issue to the .net core preview2 tooling still being flaky.
I had a similar problem, not with the build inside Visual Studio, but with msbuild. For a long time I was sure that the error was caused by dotnet tooling beeing in a preview state, but finally came upon, that one xproj-project wasn't build before another xproj-project, that was dependent of the first one. So I started looking for solutions to build-order problems instead, and came across an old blog-post by Victor Sergienko
http://victorsergienko.com/project-dependencies-of-visual-studio-2008-broken-in-msbuild/
that solved the problem by adding a dependency from the second project to the first like this:
Project("{8BB2217D-0F2D-49D1-97BC-3654ED321F3B}") = "ProjectOne", "ProjectOne.xproj", "{CAF36C07-36C7-4842-A2DA-9737005D2835}"
EndProject
Project("{8BB2217D-0F2D-49D1-97BC-3654ED321F3B}") = "ProjectTwo", "ProjectTwo.xproj", "{82875D1E-3F13-430B-8946-C26E08BD9DF9}"
ProjectSection(ProjectDependencies) = postProject
{CAF36C07-36C7-4842-A2DA-9737005D2835} = {CAF36C07-36C7-4842-A2DA-9737005D2835}
EndProjectSection
EndProject
Now my solution builds in TeamCity again... finally!

How do I integrate mSpec & ReSharper 7.0 in Visual Studio 11?

I've been trying to get these beta programs to work together. Resharper 7.0.3.261 runs just fine. After a nuget install of machine.specifications, I run the InstallResharperRunner.7.0 - VS2011.bat file which copies the mspec dll and resharperRunner dll to the correct plugins folder in my profile.
Now, whenever I create a new project (Mvc 3 or 4) resharper load throws the following error:
Initial instantiation of the component TypeComponent { MSpecUnitTestPresenter, State: Corrupted } has failed. Exception has been thrown by the target of an invocation. Could not load type 'JetBrains.ReSharper.Features.Common.TreePsiBrowser.TreeModelBrowserPresenter' from assembly 'JetBrains.ReSharper.Features.Common, Version=7.0.1.47, Culture=neutral, PublicKeyToken=1010a0d8d6380325'.
I've eliminated the possibility of corruption in the downloaded components by downloading several times, even compiling the mspec 7.0 runner and core dll from source. All variations result in the same error.
I know it's not reasonable to expect error free integration between beta projects - just wondering if someone else has run into this. My objective is just to get mspec working in VS11, and the resharper runner seemed like a reasonable option. Has anyone had success getting mspec to play nicely with VS11 Beta?

Custom attributes are not consistent errors moving a VS 2008 solution to VS 2010

I'm trying to move my VS 2008 solution to VS 2010. Everything works perfectly (compile and link) if I keep the target framework at 4.0.
When I change the framework 2.0 and change the platform framework v100 (to get past compile errors) only to run into metadata linking errors, like this one:
error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0000f7). C:\Development\Main\Filemaster\SoxService\MSVCMRTD.lib(managdeh.obj)
I've read that I'm supposed to use ILDAsm but it doesn't like my obj file and since the link didn't complete I don't have an exe to load.
Can anyone please provide some advice on how to find the sorts of errors?
I hate nothing worse than fighting the tool!
I was able to get around this problem by going into the project XML file itself and changing the TargetFramework to be 4.0 After that everything compiled and linked fine.
Hans he is referring to C++ Native Multi-Targeting which can be found at this location Platform Framework can be changed under project Properties > General and is advised by the article - however this does not work due to apparent bugs in VC++

Minimal installation requirements for compiling WP7 projects on a build server

I'm attempting to find the minimum installation requirements for getting WP7 projects compiling on a Windows 2008 R2 build server. I'll be looking into automated testing using the emulator at a later point, but right now I'm stuck on the build side.
I realise this approach won't be supported and I'm willing to trash the VM at a later date if an update proves to be incompatible (assuming I get it to work at all)
I'm also aware of the workaround for installing the entire SDK on Windows 2008 R2, but I'm trying to avoid installation of Visual Studio (it's now become a curiosity more than anything else)
As it stands, I've installed the following from the SDK ISO:
WCU\Silverlight4\silverlight_sdk.msi
WCU\WindowsPhone\WindowsPhoneExtensions.msi
WCU\WindowsPhone\VS_SDEProLightup-enu.msi
At this point, it is able to locate all the required MSBuild target files and even compiles the project. The problem appears at the end of the process during the XapPackager target, when it errors with:
Xap packaging failed. Unable to load DLL 'zlib114.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Using Process Monitor, I can see that MSBuild finds the dll in the WP7 MSBuild targets directory that installs with the SDK with the only error being "FILE LOCKED WITH ONLY READERS" error to a CreateFileMapping+SyncTypeCreateSection, which it then falls back to a SyncTypeOther, which succeeds. Despite this, MSBuild still continue to look for the dll is all the other standard locations (Framework directory, SysWOW64, etc).
Any thoughts to why it might be failing?
If you're using TFS, Justin Angel has a great post on TFS2010 WP7 Continuous Integration. Given that TFS is just wrapping around MSBuild, you may find this a particularly useful resource. When it comes to doing the unit test integration, Deyan Ginev from Telerik has a series of posts that covers this.
FYI, I ended up fixing the zlib problem by using the dll from the Silverlight SDK, rather than the WP SDK.

Build order and dependencies not preserved on upgrade from VS 2008 to 2010 with msbuild

I'm in the process of upgrading our VS 2008 solution to run on VS 2010
I managed to successfully build in VS 2010
My next step now is to configure a build machine running TFS 2008
Whenever I start a build it does my projects in alphabetical order with no regard for dependencies. I've googled a lot and I can't seem to find a solution to this.
The closest solution to my problem is found here: msdn link which links to this: dependency solution
However I'm dealing with 129 projects, so I would really rather not do this all manually in the xml.
Has anyone been able to effectively remap the dependencies in a way which msbuild recognizes without manipulating the xml for days...?
It turns out that the conversion to VS 2010 makes the build agent have to use the .NET 4.0 version of msbuild.
So I followed the steps outlined here and it worked: Building .NET 4.0 Applications Using Team Build 2008. Keep in mind that those instructions were written during the beta and the path is now v4.0.30319.
This was required even though all my projects are targeting 3.5
Basically I had to make a one line change and now everything is happy (still working on getting my build to pass but the order is good). It had nothing to do with dependencies not being preserved, simply that the way dependencies were being managed wasn't understood by msbuild 3.5
We also have a large number of projects. We wound up (programmatically) creating a MasterSolution.sln file that contained all of the projects. We also require our developers to only use project references in their code. This way, MSBuild always gets the correct order as it parses the .sln file.

Resources