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.
Related
I build my app either as x86 or x64. This app uses external DLL.
I have x64 system (Windows 10) with the same DLL library installed for both platforms - x86 and x64. They are placed in same folders inside appropriate Program Files directory. I can manually set path to either one in environment variable PATH and it woks. But it is a little incovinient to rewrite PATH and reset computer when I switch platform and want to test the other one. Is there any solution, how system automatically loads correct DLL from correct Program Files dir?
I have found solution for running apps from Visual Studio: How do I set the path to a DLL file in Visual Studio?
It is working as epxected. If I run app outise Visual Studio, I set PATH variable by myself and is also working.
Copy the DLL in the build location next to the executable, for Visual Studio this is typically \Debug or \Release in a architecture dependent sub directory (i.e. x86 or x64). Just make sure the target / output locations are set correctly in the project settings.
You have to copy only once, or more correctly: each time after you 'clean' the solution. To make this easier, many people use a dll-copy script (use batch, ruby or python) and have it run automatically before building or after cleaning. You can execute the script in a pre-build step or post-build step that can be configured in your Visual Studio solution or project settings.
There is also a more robust way to handle build artifacts and peculiarities: I highly recommend the use of CMake to keep the build matrix organized. It is provides a general cross-platform approach to script pre-build and post-build actions such as tracking dependencies, copying files, packaging installers, deployment, version verification, versioning, etc.. it comes with an easy scripting language so you can build macro's and functions to do your copying. It can be a bit of a learning curve to get it right, but once it's there, it provides a robust dependable way to build out your project build pipeline.
I have a solution which containes serveral projects (An MFC Application and the others are DLL projects). Is it possible to add another console application project (BOOST TEST) to unit test a specific DLL project, without modifying anything in the production MFC application and succeeding in building the whole solution?
I want only the test console application to run as a post build and then launching the prodution MFC application.
I wrote a series of blog posts on test-driven development in C++ that show you step-by-step how to do TDD in C++ with Visual Studio and Boost.Test. The steps would be nearly identical for your situation with the exception that your console test project depends on the DLL project instead of the static library project that I used in my article.
If I understand you correctly you want the build of the solution to compile and run the tests. If you say "build and run in the debugger" (F5), you want to compile all the code, run the tests and then run the application if the tests pass. This is not hard to do.
Set up the console unit test program as outlined in my blog posts and that will make the unit test project compile and run as part of the build. So if you say "build and run in the debugger" (F5) in Visual Studio, it will build the solution and then run the startup project, e.g. your MFC application. Since the solution contains the unit test console executable project, it will build that project. The unit test project has the post-build step to execute the tests, so the tests will run as part of the build.
Because your unit test executable depends on a DLL, you will need to make sure the DLL is found by the executable at run-time. You may need to add additional commands to your post-build step to copy the DLL to the necessary directory before running the test executable. You can verify this works properly by setting your unit test project as the startup project and running it in the debugger.
Double check in the configuration manager that all the projects are set to build for your combination of platform and configuration. Sometimes if you have customized these in your solution when you add a new project it isn't automatically checked to compile in the custom platform/configuration combination.
If this isn't working for you, then add a comment or edit your question to include more specifics about what isn't working.
I'm developing a C++ project in Visual Studio 2012 that uses driver code to interface with an open DMX box(ENTTEC DMX USB PRO). Thus far, I've been writing code and compiling as an EXE so I could use main() to run unit tests.
I want to port this over so that I have the device interface code that compiles down to a .DLL, then a separate source file that contains C++ code to compile an EXE that links to the DLL and makes calls to the functions to run the tests.
Essentially, when I go to debug, is there a way to setup Visual Studio 2012 to generate a .DLL and an .exe making calls to the .DLL and run the .exe automatically all in one step? I'm new to Visual Studio and find it quite confusing.
Yes. Setup two projects in your solution: One for your main code (generating a DLL) and one for your executable, where your unit tests reside. Then look under project dependencies (under the Project menu on VS2010, not sure about 2012) to make the EXE dependent on the DLL (that will make sure the EXE rebuilds/relinks when necessary).
Right-click on the EXE project in the Solution Explorer and select Properties. There you can setup the includes/linker to get to your header/lib file, if necessary (it might not be necessary if you use LoadLibrary explicitly or something, but I'm guessing you're not doing that).
Now in the project settings for the EXE under build events, add a post-build event that runs your tests. Note that if your EXE returns something other than 0 from main(), VS can report that as an error in the build.
I'm a fairly experienced C# dev, but have very little C++ knowledge. I have set my self a project to get a custom Firefox build running, and be able to control it from C# code.
I have got so far as getting and building the Firefox source, and creating a Visual Studio solution for the exe. This means I can now run via F5 in Visual studio. If I open a source file, I can set break points and have them hit.
What I'm not sure how to do, is load the entire source, as if I were working with a C# .NET solution. As I understand it, there are no project files with the Firefox source, as it is not windows specific source. I have followed an online example that suggests creating using 'project from existing code' option in VS, which resulted in VS grinding to a halt as there were so many files.
What are the steps to getting the code into an environment (preferably Visual Studio) that makes it simple(ish) to edit, debug and navigate the source code.
Note: Instructions I have been working through so far are here: https://cs.senecac.on.ca/~david.humphrey/writing/debugging-firefox.html
From you question, I beleive you are almost there. You have a working build ? That means you have :
A Solution File (*.sln)
A Project file (*.vcxproj or *.vcproj depending on yoru visual studio version)
With that in hand, what works best for me is this layout (adapted to your needs) :
Starting from a root folder of you liking, say MyProject
Create a new Empty solution there
Move the folder with your working build in a subdirectory, like MyProject\MyCustomFirefox
In Visual Studio "Add an existing project" and find your vcxproj file
In the same solution, create a C# project like you always do, in a directory at the same level as your FF build, like MyProject\MyFirefoxController
In short the solution file is pretty much alone in the root directory, and each project is in its own directory.
You will also need to adjust build options so that the output files (a DLL or an EXE) is seen by your C# project. While your are at it, make the C# project dependent on your Firefox build : it will instruct the msbuild to rebuild one if you change the other.
This will not work with the Express edition, I beleive. They are single language.
If you have a command line build path, which is creating a VS-debuggable executable, you could try adding all the source files to the project, but marking them 'exclude from build'. Then add a 'post-build step' to call the command line tools.
You may have to do a little more tweaking in the project properties to get the command line output recognized as the output to debug, but theoretically this could work.
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.