Seems like I may be missing to set some enviornment variable in my AppHarbor environment.
My test folder cannot find reference to the nunit framework. I am using NUnit 2.5.9.
Part of the build output is pasted below. Any ideas what am I missing?
Primary reference "nunit.framework".
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3245: Could not resolve this reference. Could not locate the assembly "nunit.framework". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [D:\temp\oyiirwgf.sjw\input\JeeneeTest\JeeneeTest.csproj]
For SearchPath "{HintPathFromItem}".
Considered "..\..\..\..\..\..\..\Program Files (x86)\NUnit 2.5.9\bin\net-2.0\framework\nunit.framework.dll", but it didn't exist.
For SearchPath "{TargetFrameworkDirectory}".
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\nunit.framework.dll", but it didn't exist.
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\nunit.framework.exe", but it didn't exist.
For SearchPath "{Registry:Software\Microsoft\.NETFramework,v4.0,AssemblyFoldersEx}".
We (AppHarbor) recommend you use the NuGet Nunit package. You can either commit the /packages folder along with your code or use NuGet package restore to make the NuGet package work as part of you AppHarbor build.
Probably you added reference to NUnit, which is installed on your development PC (path points to NUnit installation folder: Program Files (x86)\NUnit 2.5.9\bin\net-2.0\framework\nunit.framework.dll). There are two options to fix this:
Install NUnit on PC where you running tests
Use a reference to local nunit.framework.dll in your tests project
I prefer second one.
Related
I'm using the built-in Google Test Adapter to write unit tests for a project in Visual Studio 2017. When I create the unit test project in my solution VS creates a package directory with the libs and header files for googletest, along with a package.config file. However I'd like to keep the googletest files out of my solution directory (and source control, though obviously I could just ignore them), and in a shared directory like the windows or standard library headers.
How can I configure my solution to get the libs and header files from a shared directory outside of my solution?
Not quite the answer I was looking for, but I learned that Visual Studio can automatically download NuGet packages when they are missing from solutions. Therefor you can just ignore the package directory from your source control but include packages.config, and whenever you clone the project Visual Studio will download the missing packages. This was good enough for my needs.
I have a cmake project that builds fine on Linux and that I want to build also on Windows. The code is portable and is made of C++ so... it should build. The only thing is that, on Windows, I need to use nuget to restore some packages, cpprestsdk is one of them. Now when I run
cmake .
CMake will generate solution files and projects files that I don't want to include in my VCS at all. The thing I want MSBuild to do is to apply the packages contained in my packages.config to all the project files found in the project directory.
Anyone knows how?
The thing I want MSBuild to do is to apply the packages contained in my packages.config to all the project files found in the project directory. Anyone knows how?
I am afraid you can not do such things. That because whether you are using MSBuild or NuGet to do this thing, you have to use to the nuget.exe to do it. However, install nuget packages to the project file relies on VS capabilities not nuget.exe and nuget team not plan to bring it to the exe.
The NuGet Command Line does not actually install any packages. The install command is actually doing a restore operation.
This means that nuget.exe install will only download and extract the package into the output location. It will not modify the project file. Although, the package manager console seem to offer "Install-Package" for doing this, but you have to open each project files with Visual Studio and execute Install-Package in the package manager console for each project files, which is not what you want. So you could not enable this script outside of visual studio.
So we could not use MSBuild to apply the packages contained in the packages.config to all the project files found in the project directory.
You can refer to this thread and this thread for details.
Hope this helps.
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.
Previously, when I had only Visual Studio 2010, my unit tests were executing fine.
Basically, my tests are composed of two files: UnitTests.dll and UnitTests.dll.config. Where UniTests.dll.config had a custom probing privatePath (e.g., Public;Extensions;Lib)
In order to execute, I used to follow this workflow:
1. I copied both files (i.e. UnitTests.dll and .config) to the folder were my application under test is located.
2. Open NUnit gui.
3. Execute the tests with ShadowCopy disabled, because my tests need to load the dlls from my application under test.
This was working fine!
After I installed Visual Studio 2012, the tests were not running anymore. And later, I figured out a workaround, but it is something that I don't want to use in my solution.
Now, I have to follow this workflow to make the tests running:
I copy both files (i.e. UnitTests.dll and .config) to the folder where my application under test is located.
I copy all the NUnit installation files (i.e. nunit-agent, nunit-console, etc.) to the folder where my application under test is located.
I change the probing privatePath from nunit-agent.dll.config in order to include the same paths from my UnitTests.dll.config.
Open NUnit gui which is located in my application under test folder.
Execute the tests with ShadowCopy disabled.
Note that I had to include steps 2 and 3 in order to run my unit tests. Somehow, I think nunit-agent.dll is not loading the probing privatePath from the config file of my test assembly.
Does anyone know why this is happening? Does anyone have a workaround where I don't need to change the nunit-agent.dll.config and copy the nunit installation files?
Thanks in advance.
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.