rig: win7 64bit, vs2010, mvc v2, TestDriven.Net 3.0, Reshaper 5.0, MSpec 0.3
i recently started a new project and want to use mspec.
(1) copied Machine.Specifications.ReSharperRunner.5.0.dll and Machine.Specifications.dll to JetBrains\ReSharper\5.0\Bin\Plugins\Machine.Specifications (2) copied Machine.Specifications.TDNetRunner.dll to TestDriven.NET 3\Machine.Specifications
when i try to run the test i get this error: System.IO.FileNotFoundException: Could not load file or assembly 'Machine.Specifications
i don't know where this error is coming from.
vs2010 menu -> ReSharper ->Plugins shows the MSpec plugin. vs2010 menu ->ReSharper -> Options -> Tools -> Unit Testing also shows the MSpec unit testing provider but it doesn't show any details when i click on it as does MSTest and nUnit.
i found this: http://marcinobel.com/index.php/mspec-bdd-installer/ which didn't work. i also tried this: http://eduncan911.com/blog/registering-mspec-runners-for-testdriven-net-on-windows-x64.aspx which also didn't work. now i fear i screwed my registry.
any guidance?
full error:
Test 'F:Tests.OTBRadio.Tasks.AlbumTasksSpecs.when_the_album_tasks_are_asked_to_get_all.context' failed: Could not load file or assembly 'Machine.Specifications, Version=0.3.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
System.IO.FileNotFoundException: Could not load file or assembly 'Machine.Specifications, Version=0.3.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
File name: 'Machine.Specifications, Version=0.3.0.0, Culture=neutral, PublicKeyToken=null'
at Machine.Specifications.TDNetRunner.SpecificationRunner.RunMember(ITestListener testListener, Assembly assembly, MemberInfo member)
at TestDriven.TestRunner.AdaptorTestRunner.Run(ITestListener testListener, ITraceListener traceListener, String assemblyPath, String testPath)
at TestDriven.TestRunner.ThreadTestRunner.Runner.Run()
You do not need to copy Machine.Specifications.TDNetRunner.dll anywhere, just place it in your project's tools or lib directory, i.e. where you keep your project's dependencies. The project containing the MSpec tests will reference the Machine.Specifications.dll from this directory. TestDriven.Net >=2.24 will be able to pick up the TD.Net runner as long as Machine.Specifications.dll.tdnet is located in the same directory. An example how I like to organize my tools directory can be found here.
Your ReSharper 5.0 plugin directory looks good to me. However, I've had users reporting that when you unzip the MSpec zip file (that you likely downloaded from http://teamcity.codebetter.com) using Explorer, Windows marks the extracted DLLs as being downloaded from the Internet.
Can you please make sure that Windows does not block the DLLs in <ReSharper 5.0>\bin\plugins by opening each DLL's properties and clicking "Unblock" on the first property page. In case the "Unblock" button is not displayed, your files are okay. In that case, please post here and we'll see how we can your MSpec plugin working.
After changing any dll you should clean up project - so you don't have any errors in fresh project.
I also had the same problem and I fixed it by cloning a copy of MSpec off Github (https://github.com/machine/machine.specifications).
Then in the "Source" folder I ran one of the batch files (in my case build-4.0-debug.cmd) which created "Machine.Specifications.dll" in "xxx\Source\Build\Debug".
I removed the references to the "old" dll, cleaned up my project, copied over the old dll with the new dll I obtained in the previous step, rebuilt and that did the trick.
Related
I have an ASP.net MVC 3 project. We're using TeamCity, and up until now everything has checked in fine. All of a sudden today, I did a checkin, and the TeamCity build failed. It said I was missing a using directive or assembly reference and threw a compilation error.
The project on my local machine builds successfully. I rebuilt it several times to make sure. I checked the reference and it's there. I checked the .csproj file and it has the reference there too. I checked bin; it's there. I even RDPed into the server where our site is deployed and checked the bin there, and the dll file is there too.
I don't understand why it's not working, I haven't changed anything in the particular files it says are missing the assembly reference in weeks, I had a successful checkin on TeamCity yesterday, the dll file exists everywhere it's supposed to, and my project builds. I even did a hard reset to the last commit I made that checked in successfully, added my changes back in (which had nothing to do with the reference problem, all my changes were in a .js file), and checked that in, but I got the same compilation error.
Does anyone have any idea what's going wrong, or at least what I might try to resolve this?
edit: There are no path files being used here, the file in question is a .dll file, which I added by clicking "Add reference" on the project. I checked the Github repository and the .dll file is in the bin folder
iamkrillin got me thinking that maybe it was a path issue, so I opened up the csproj file and noticed that the format of the reference to "missing" file was different from all the others around it:
<Reference Include="Ektron.Newtonsoft.json">
<HintPath>..\..\Custom\bin\Ektron.Newtonsoft.json.dll</HintPath>
</Reference>
// THE "MISSING" FILE
<Reference Include="Smdg.Utils, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\NEHGS\bin\Smdg.Utils.dll</HintPath>
</Reference>
I checked the Custom\bin folder and sure enough the .dll file was there (though it also existed in NEHGS\bin), so I got rid of the SpecificVersion tag and changed the path to the Custom folder. TeamCity was able to check it in.
Why it suddenly broke when it's been working for the past 2 months, I have no idea.
I had this just because of not storing NUGET packages at VCS (GIT).
So there is the need to do the restoration of NUGET packages, just before a build step.
https://blog.jetbrains.com/teamcity/2013/08/nuget-package-restore-with-teamcity/
I had the same issue of my TC build suddenly being unable to find an assembly. I solved it by checking in the paths as well. My assembly did not have a tag. Once I added the tage with the path to the dll, TC was able to build successfully
I hope this helps someone out there, in my case I had to check in the folders that had the reference dll/nuget packages. Note that I had already committed the project but for some reason 'SVN' did not check in/ commit the (local) folders that had the dll/ nuget packages so I had to go to the folders and check them in.
I know about this question (and answers), but despite trying all the suggested options I am still stuck.
I have a solution with multiple projects, but for this particular case let's say I've got my ExampleProjectA and a corresponding unit test project ExampleProjectATest. The first one is added as a reference to the test project - not via Visual Studio's "Project References" but as a link to the DLL (something like "..\Path\$(Config)\ExampleProjectA.dll") - this is due to build server requirements in our company, but the problem also existed when we still had "Project References".
Building and then running a single unit test works fine
Changing just a single letter in a unit test and then letting the test run always results in a rebuild of ExampleProjectA, even though this shouldn't be necessary
Setting all (there were only a few) files in ExampleProjectA from "Copy always" to "Copy if newer" in their respective properties didn't help
Checking the checkbox under Tools => Options => Projects and Solutions => Build an Run (see below) also didn't change anything
To see if there was any more information available, I changed the build output settings to diagnostic. Each time a rebuild of ExampleProjectA is triggered, the first line in the output windows is
1>Project 'ExampleProjectATest' is not up to date. Input file 'c:\tfs\mysolution-dev\exampleprojectatest\myfolder\namegeneratortest.cs' is modified after output file 'C:\tfs\mysolution-dev\exampleprojectatest\bin\Release\exampleprojectatest.pdb'.
The class name written to the window (e.g. namegeneratortest.cs) changes according to which test file I change.
Not sure why this message comes up, but the next step was to disable the debugging information as shown below under Project properties => Build => Advanced => Output => Debug Info => None:
Still the same, nothing's changed.
Another thing I tried was to check the timestamps of the files contained in my solution folder (as there was a case where a user had a file with a future timestamp - see linked post) - to no avail.
Last thing I tried was to change the build settings in the Configuration Manager to a different target platform - some settings wouldn't let me build the solution successfully, some other settings did, but the problem described persisted, so no change.
The behaviour is similar (not the same though) with both the Visual Studio Test Runner and the one provided by ReSharper.
Visual Studio Test Runner
Project 'ExampleProject' is not up to date. Input file 'C:\tfs\mysolution-dev\exampleprojecta\Views\Shared\someview.cshtml' is modified after output file 'C:\tfs\mysolution-dev\exampleprojecta\bin\exampleprojecta.pdb'.
ReSharper Test Runner
Project 'ExampleProjectATest' is not up to date. Input file 'c:\tfs\mysolution-dev\exampleprojectatest\myfolder\namegeneratortest.cs' is modified after output file 'C:\tfs\mysolution-dev\exampleprojectatest\bin\Release\exampleprojectatest.pdb'.
I'm using Visual Studio 2013 Premium Edition with ReSharper 8.2 and the latest updates, the projects in our solution file are in C#.
Update
To clarify - the first line in the output window does show that the test project has to be rebuilt - this is fine. The following lines, however, indicate that also ExampleProjectA has to be rebuilt, which shouldn't be necessary. Subsequent messages to the output window also show that other projects (referenced from ExampleProjectA have to be rebuilt.
Update 2
Despite installing Update 4, nothing has changed.
For my case the solution was to change the build action of a config file from "Copy always" to "Copy if newer". It took a while to find as I had to change the build output details to get the details about which file was causing the error, e.g.
Project 'xyz' is not up to date. Project item 'c:\my\path\web.config.dev' has 'Copy to Output Directory' attribute set to 'Copy always'.
From my experience it can also happen that different file names are shown when building multiple times, so make sure you have the right one and / or build again if the problem persists.
Also have a look at this question and its answers to find some more information.
I have worked around this problem by deleting the .pdb file in the \obj folder. It seems that visual studio is checking file modification time to decide if it should build or not the project (in your case ExampleProjectA) and the .cshtml is newer than the pdb. But when launching the build, project changes in .cshtml files are not triggering the .pdb rebuild, so the problem remains.
By deleting the .pdb in \obj folder (not in \bin as the file there is copied from \obj and would keep the old modification time) the modification time for the .pdb is newer than the .cshtml and the VS doesn't need to build the project before running the tests. Of course this only works until the next time you modify a .cshtml file, that's why I qualify it as just a workaround.
Check what version of Visual Studio 2013 you are using. Update 1 has a pretty big issue where it rebuilds everything. See: https://connect.microsoft.com/VisualStudio/feedback/details/811112/unnecessary-solution-rebuild-on-each-test-run
Upgrading to Update 3 did the trick!
I'm not sure if Resharper could affect things as well. I suggest temporarily uninstalling it.
I am trying to build and run Google Test but encountered some issues.
Any help greatly appreciated.
I used CMake 2.8 (with UI) to create .sln and .vcproj files in the D:/MyBuild
directory (as mentioned in the README file of google test).
However, when I try to run the .sln file in the MyBuild directory,
here is what I get (image):
Also, here is a screenshot of the CMake which I used to
create .sln files and .vcproj files in the D:/MyBuild directory.
ps. One thing I noticed is that README was giving instructions how
to use non graphical version of CMake (e.g., 2.6) to install
google test, however I used one with user interface - maybe
I did something wrong there?
You appear to have successfully built gtest's libs in Debug mode. However, by default the .sln doesn't contain any executables, so you can't actually run anything.
If you select the checkboxes in the CMake GUI for gtest_build_samples and/or gtest_build_tests and hit "Generate", then the Visual Studio solution should contain some executables.
From memory, these don't build cleanly, but I don't have MSVC 2010 to hand, so I can't be sure.
Whenever I try to run any of the test from my test suite in Visual Studio 2012 I get
Test Failed - [test method name]
Message: Failed to set up the execution context to run the test
and my test is not even started (i.e. the source of the test failure is pointing at the beginning of the test method:
here--> TEST_METHOD([test method name])
{
}
What does this message mean, what could be the cause for it to appear and what should I do for my test to run correctly?
After some more research I realized that I overlooked the fact that I changed the 'Output Directory' of the project containing the methods under test (which was a .dll) and was not in the same folder as my test project library, hence giving me the message:
Message: Failed to set up the execution context to run the test
So the problem was solved by making sure that the .dll containing the methods under test was in the same folder as my test project library so that at run-time my test project could find the .dll.
I had the same issue and the previously mentioned suggestions did not fix it for me. My project uses some third party libraries and the paths to these are set up correctly in the compiler and linker settings of my VS project.
It turns out that the VS test engine was unable to find the libraries, so I added the paths to these libraries to the PATH environment variable. This fixed the issue for me.
Tip: Try running the unit tests from the command line using VSTest.Console.exe. The error messages helped me debug my issue more easily.
For those searching for other answers, this turned out to be a problem finding all the DLLs needed. I followed the advice above getting both the test dll and the dll to be test in the same location but still got this error.
My test DLL, out of its native environment, couldn't find its children DLL. You can figure out what is missing by running depends.exe . Adding the locations to these other DLL's to my path resolved the problem and everything now works.
I was getting this error, and it was because I was using a debug DLL, and did not have debug c++ runtimes where they could be found. I copied the debug c++ runtimes into the same directory and the issue was resolved.
I had this error after including a third party dll (OpenCV) in my project. Adding the dll to path or dropping it in the system32 directory does work, but I have a better solution.
The test is run from a directory called AppX. In my case it is here:
.......OneDrive\Documents\Visual Studio\Projects\TutorialOcr\x64\Debug\OcrTesting\AppX
I just dropped the dll in there and the test worked!
The .dll created for the tests is run from the folder where it is built to. In my case "x64\UnitTests\Tests.dll". The rest of my application is in "x64\Debug\App.exe" and "x64\Release\App.exe".
My application depends on external dlls which are located in the root folder of the project, which is also the "Working Directory" specified for debug launch.
But the Test Explorer test launcher ignores that setting and always launches Tests.dll with working directory "x64\UnitTests", and then fails to find the dlls I depend on. Adding SetCurrentDirectory("..\\.."); in, say, the test class constructor does not fix the problem, because the dll cannot even be loaded into memory if the static dependencies are not found.
I solved it by just setting the "Output Directory" to "$(SolutionDir)" for the UnitTests configuration. This causes the Tests.dll to be created in the root folder.
I was also getting this error only in the Release configuration, because I accidentally used a debug lib as one of the library dependencies of my test project. ( same problem as bmann's post )
To find which library was causing the problem, I commented out all the test code and its includes, added one empty test, and removed my dependency libraies one by one until the test worked.
I'm trying to build a project with TeamCity Professional 6.5.2
I have a MVC Visual Studio 2010 project using a visual foxpro dll.
The build fails because the dll is not registered.
How can I register that dll in the build machine, as part of the build process?
Thanks!!
There are two different scenarios Rodrigo, your scenario will fall into one of these:
Assemblies which can be referenced by the project: Wherever possible, include dependent assemblies in your source control repository (the 10th Commandment), usually in a "libs" folder which is referenced by the necessary projects. This centralises all your dependencies, makes it easy for new developers to get started and solves your TeamCity build problem.
Assemblies which need GAC installation: There are times when the assembly simply has to be installed in the GAC (i.e. RightFax). Frankly, the easiest thing to do in this case is just to install the damn thing in the GAC. It's an exception and whilst some people will philosophically argue against it, alternatives can get a bit complex (i.e. automating installation as part of the build), and for money I'd rather invest the time elsewhere.
Installing assemblies on each machine (dev, build, prod) will make future updates and any continuous integration system difficult to maintain in the future.
It would be better to create a folder in your working directory (I call it "Resources") which contains a folder for each group of DLLs. Then you just reference the assembly directly from the Project each time. You get duplicate DLLs across different projects, but it keeps everything very clean and simple.
In Visual Studio 2010 you can download a little utility called NuGut which I believes helps to manage assemblies in a better way.
It is a bad idea to register all DLLs on build agent machine, sometime you can find out that you have to install Visual Studio on a build agent machine, for instance ;)
I would suggest to place such libraries along with your code base in Source Control system (I assume you are using it), and just reference lib's folder by declaring a MSBUild property like
<PropertyGroup>
<LibFolder>$(PathFromCommandLineOrJustHardCodedPath)</LibFolder>
</PropertyGroup>
And then before doing a Build/Compile just copy files from $(LibFolder) into the build $(OutputFolder) using standard MSBuild command Copy by specifying source and destination files, and thats it.
To force TeamCity to pickup Lib (dlls) files from VCS folder just add path mapping into the:
TeamCity Configuration Settings -> Edit Build Configuration -> VCS Root settings -> Client Mapping
EDIT:
In your case looks like you have integration test which depends on external COm Server which you need to launch, so you can programatically registr this DLL, for instance in TestSetup, and then do not forget to unregister it in test TearDown.
Anyway you have to just reference this DLL as
VS Project -> Add Existing Item -> Add as Link
+ set
Copy to Output Directory -> Copy if newer
How-To register COM dll: see this SO post
Finally I added a prebuild event in Visual Studio running the regsvr32 command. The dll was in a known location, so I referenced this way:
regsvr32 /s $(SolutionDir)Lib\ProjDataAccess\ProjDataAccess.dll
Agree with Troy Hunt.
For a Continuous Integration with TeamCity 8.0.2 where you need an assembly (custom made shared assembly) reference from GAC, do the following.
1. Add the assembly to the build pack (In my case its nuget package).
2. Before starting the build process (MSBuild, Visual Studio etc), register the assembly to GAC with the help of a command line build runner.
3. Continue with the build process.
By following the above steps, if you are using MSBuild, the build process can link to a valid reference from GAC, which can produce an expected build result.
In my case, where the code refers a custom component from GAC, MSBuild ignored the assembly reference and completed the build process without an exception. But the deployment with the build output failed. To overcome this situation, I've used the give steps.
Note: It is mandatory that the TeamCity agent needs to run under an elevated user account. Else the addition to GAC won't be permitted and the build process can fail.