Is there any way to set an execution path for the tested DLL so it can find resource folders when MbUnit copy files into a temporary folder without using Dependency Injection?
Trying to put these extra files as content and set behaviour to copy did not work.
If you are running these tests from the command-line, NAnt or MSBuild you can specify the application base directory and working directory arguments.
There are similar mechanisms available using Gallio Icarus or the ReSharper integration.
Related
I'm working on a big code base which has many solutions and many more projects.
When I write unit tests they often depend on a number of dlls being present which are built by other solutions into different output folders to my current solution.
I usually add build steps to copy required dll's to the current solution's output folder so that they can be found when I run unit tests. This can end up in a lot of wasted space and confusion with duplicate dlls and which is the master copy of each dll which is the one that should go into the installer.
Is there a better way of adding additional search directories?
I was considering having a TEST_MODULE_INITIALIZE that will AddDllDirectory() and then marking the dll's as delay loaded so that when they do load the added dll directory will be searched. But, I don't think that works as you have to mark the dll's as delay loaded in the exe. But, the exe is the testrunner which is out of my control.
Your consideration is absolutely right. You can load dependency dlls in VS testrunner context, as sure as a gun, in this way:
1) setup your test project to deploy all required dlls into output dir (for example with the help of pre\post-build steps)
2) set delay loading of dlls in test project settings. (Test project-properties-Linker-Input-Delay loaded dlls = enter list of dependency dlls)
3) Setup directory to search dlls. It could be either TEST_MODULE_INITIALIZE or TEST_CLASS_INITIALIZE. Simple case is to use SetDllDirectory for this purpose. If you want to use AddDllDirectory - use it carefully:
If SetDefaultDllDirectories is first called with LOAD_LIBRARY_SEARCH_USER_DIRS, directories specified with AddDllDirectory are added to the process DLL search path. Otherwise, directories specified with the AddDllDirectory function are used only for LoadLibraryEx function calls that specify LOAD_LIBRARY_SEARCH_USER_DIRS.
It may not be the best method, but since you're using Visual Studio 2013, you should look into test settings to control what is deployed when you run your tests. Inside of test settings you can specify files or folders in the Deployment section which will allow you to select files outside of your current solution. You can create multiple test settings (one for local and one to use on a build server if the paths to these files are going to be different).
Again, maybe not the best solution, but it has worked for me in the past.
Specifying Test Settings for Visual Studio Tests -
https://msdn.microsoft.com/en-us/library/ee256991.aspx
I want to run my (working) msunit tests with teamcity. Within my test, I need several files which I successfully copied using either one of the following ways (when running the tests from within VS):
file properties -> copy to output directory
or copying them using a post build step using xcopy
As post build actions I tried:
xcopy /Y "$(ProjectDir)*somelib*.dll" "$(TargetDir)"
or
xcopy /Y "$(ProjectDir)*somelib*.dll" "$(OutDir)"
As you can see, I have somelib.dll files that need to be copied. This is due to the usage of a library, which I listed as a reference. This lib is copied corretly, but it needs some older (c++) dlls, which are not included in the reference package.
Unfortunately I could not find a way to either get TeamCity to run the msunit test within the bin/debug/ folder, or to copy all neccessary files to the working temp folder.
(My goal is to run all unit tests from several test suites and to gather results from dotCover for all tests.)
What is a good way to deal with this situation? I noticed the possibility to pack files into the assembly as resources, and to unpack them inside the unit tests right before they are needed. I will need the dlls in every test and would like to keet it DRY - is this a wise way to "just" copy the files?
As far as TeamCity is concerned, you can make sure the process works when run from the command line (n the TeamCity agent machine, in the same directory, etc.) and then replicate the same steps in a TeamCity build. Since TeamCity just launches MSBuild as external process and executes the configured commands, there should be no TeamCity-specific peculiarities.
Is there a way to set breakpoints and step through them using NUnit with a mixed project of native C++ and managed C++?
I have my SUT (Software Under Test) configured as a static library (native C++)
I have my unit test suite as a separate project configured as a dll that depends on my previously stated library. I also added said library as a reference to my unit test project.
My tests run fine in NUnit, breakpoints just don't work.
Again, is there a way to get the breakpoints to work with NUnit with Native/Managed C++?
The most convenient way to do this is to set up a custom tool entry specifying the path to NUnit as the command. For a VS2003 C# project, you can use $(TargetPath) for the arguments and $(TargetDir) for the initial directory.
With Visual Studio VS2005 this becomes a bit harder, because that release changed the meaning of the 'Target' macros so they now point to the intermediate 'obj' directories rather than the final output in one of the 'bin' directories. Here are some alternatives that work in both versions:
$(ProjectDir)$(ProjectFileName) to open the VS Project rather than the assembly. If you use this approach, be sure to rename your config file accordingly and put it in the same directory as the VS project file.
$(ProjectDir)bin/Debug/$(TargetName)$(TargetExt) to run the assembly directly. Note that this requires hard-coding part of the path, including the configuration.
If you would like to debug your tests, use the Visual Studio Debug | Processes… menu item to attach to NUnit after starting it and set breakpoints in your test code as desired before running the tests.
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.
I am working with Visual Studio 2010 and it's integrated testing functionality.
I have an XML file in my project which is set to copy to the output directory. I can access the file just fine when I compile and run the project. But it doesn't exist when I attempt to access it within a TestMethod.
It looks like the test is run with the working directory set to an "Out" directory created within the TestResults directory. I can set a breakpoint before I use the file. If I then copy the file into this "Out" directory and continue running the test it accesses the file properly. But that is not really how I want my automated tests to function.
Is it possible to tell VS to copy the build directory into this working directory?
I found somewhat of a solution. Though I'm not too happy with it.
Under the Test->Edit Test Settings I edit the current settings.
Under the Deployment tab, check the Enable deployment checkbox. In the Additional files and directories to deploy add your bin\Debug directory (looks something like src\LocalModels.test\bin\Debug)
I suppose you could add each file you need and it would be a bit faster. It all seems a bit ridiculous.