I have a local .Net Standard 2.0 library project and separate Xunit test project as part of a VS2017 solution. Library and Xunit tests successfully build with VS2017 and tests all succeed.
I uploaded the Git repository to VSTS. I am attempting to Build the two projects and then run the tests. The Restore step succeeds. However, the Build step successfully compiles the library, but the tests fail because the reference to the library dll is not found.
I have searched the Internet and have not found anything that helps me solve this. I assume that there is something simple to do that fixes this but ....
Related
I'm using VS Code Test Explorer with python extension on a project. It is awesome. If I change any source files, the relevant tests in Test explorer will be highlighted as out of date so I know I have to run them again to check everything is ok.
I'm trying to do the same thing with a C/C++ project and the Test Explorer Catch2 extension. I have a simple meson project file to build my test executable(s).
It works well in that my tests are discovered and I can run them, HOWEVER if I change a source file it the tests wont show as out of date to indicate that they need to be rerun.
I know this is a dependency issue with meson (or what ever build system that VS Code understands).
Is there a Test Explorer (or VS Code) way of for determining which exes are out of date and need building (tests and build in general)?
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 have a solution which was compiled with compiler VS2008. It was working perfect. It is instrumented with Google Test and the Google Test library is linked to the solution. the gtest.lib should be compiled with the same compiler as the solution itself, as far as I know.
Now, I have to compile this same solution with VS2013. I get this compilation error
Error 3 error LNK2038: mismatch detected for '_MSC_VER':
value '1700' doesn't match value '1800'
I think that I should get the library for Google Test compiled with Visual Studio 2013.
I cannot find such thing. Could you give me a hint at the Google Test library I should go for ?
The linker error you get is pretty obvious: You need a gtest.lib compiled with VS2013.
"I think that I should get the library for Google Test compiled with Visual Studio 2013."
Exactly, so just do that.
"Could you give me a hint at the Google Test library I should go for ?"
Well, no more as to cite from the google test primer documentation (emphasis mine), sorry (I doubt you can reliably download a proper binary elsewhere):
Setting up a New Test Project
To write a test program using Google Test, you need to compile Google Test into a library and link your test with it. We provide build files for some popular build systems: msvc/ for Visual Studio, xcode/ for Mac Xcode, make/ for GNU make, codegear/ for Borland C++ Builder, and the autotools script (deprecated) and CMakeLists.txt for CMake (recommended) in the Google Test root directory. If your build system is not on this list, you can take a look at make/Makefile to learn how Google Test should be compiled (basically you want to compile src/gtest-all.cc with GTEST_ROOT and GTEST_ROOT/include in the header search path, where GTEST_ROOT is the Google Test root directory).
Once you are able to compile the Google Test library, you should create a project or build target for your test program. Make sure you have GTEST_ROOT/include in the header search path so that the compiler can find "gtest/gtest.h" when compiling your test. Set up your test project to link with the Google Test library (for example, in Visual Studio, this is done by adding a dependency on gtest.vcproj).
If you still have questions, take a look at how Google Test's own tests are built and use them as examples.
I personally prefer to build the test runner using the src/gtest-all.cc to be built and linked with my test-projects from source. That's the most simple and mostly portable way IMHO (using e.g. your custom GNU makefiles).
As said in the comment on your OP, you can easily do a "prebuild" just using your VS2013 compiler, to link with it from other projects.
Note that there's a native GTEST package on NuGet which contains a gtest.lib. Has the additional benefit of making the gtest include folder automatically available.
I have DLL plug-in, which I'd like to test and launch on TeamCity: it contains .h and .cpp files
What is the right strategy to test this DLL:
Create a new Test Project in the same solution, configure 'include directory' to see sources and copy DLL project files to Test console project. In this case I have the same solution but in console mode, which I can test in normal way. But if my DLL project will change I need to synchronize source files.
Create export function in my DLL, like 'runTests()' which will produce XML file with results. TeamCity will process this? And how should it run this? And some stuff function appears in release DLL...
To unit test our libraries, we create standalone unit testing console executables. so:
For each library , we create a console executable testing each method in the API.
Each source file is obviously added to a SCM so modifying files will automatically be reflected into the unit testing program;
All this (source updates, compilation, unit testing and doc generation) is added to our CI server (Jenkins) so that all libraries, for all unit testing programs are always recompiled from scratch;
The documentation for the library API is constructed with Doxygen using snippet from this program. This has a nice side-effect: changing the API will break your unit tests. So you have to fix your unit tests so your documentation is always up to date.
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.