My company is moving to continuous integration using Jenkins.
We keep our code in Subversion.
We code in C# (well I do, the others use php).
I've hit a snag, I can't get nUnit to work when I compile the project .
My project is a very simple one with just a single class and a few nUnit tests.
Works fine in Visual Studio. It builds and I can run the NUnit console to test the code.
I can use Jenkins to extract the project from Subversion
I can then build the code with msBuild.
However, when I try to run NUnit from the the NUnit console I get told that nunit.framework.dll is missing.
nunit.framework.dll is in C:\Program Files (x86)\NUnit 2.5.10\bin\net-2.0\framework
I think it is looking for the nunit.framework.dll that is referenced by the project. Which is required to add NUnit tests to the project.
I note that when building from Visual Studio nunit.framework.dll is copied to the bin folder.
I note that no contents of bin are stored in Subversion.
I had to put a copy of nunit.framework.dll into
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\Profile\Client
so that msBuild could find it.
How do I get nunit.framework.dll into the output bin folder when using Jenkins and msBuild?
I've looked through a number of posts but non address this point.
Any thoughts would be welcome.
Thanks,
Richard
In your Test project where you reference the Nunit.Framework.dll, right click on that and select properties ( or press Alt + Enter ) and make Copy Local to be True
Subversion does not store output files ( i.e. dlls) by default. I rebuilt the project and added nunit.framework.dll to subversion. That way it gets popped out by Jenkins and can subsequently be referenced.
Related
I have a visual studio 2019 solution with a few projects that consist of mostly c# class libraries. This solution is never 'deployed' and is always run locally by anyone who uses it. Part of what we do for one of our test projects to work is put certain dll's we use into our bin/Debug folder. One of these is Newtonsoft.Json.dll for example. We have a specific version of that dll that we're required to use.
This is something that is usually done once, the first time we run a test in that project. This all works fine. However, whenever there is a code change and the project builds, for whatever reason all the files that are in "C:\Program Files\IIS\Microsoft Web Deploy V3" are copied into our projects bin/Debug directory and overwriting any of the same files already there (Newtonsoft.Json.dll being one of them), and it's a different version which then breaks our projects dependency on that version of the dll. It's worth nothing there are also a bunch of random other files/folders in that Web Deploy directory that get copied over that our project does not need to be there.
I've checked all build events, and searched the entire solution to see if we reference that directory at all which we don't. I've tried googling similar issues, but almost all of what I can find is related to how to use Microsoft Web Deploy (which as far as I can tell we're not, and intentionally as I mentioned we don't deploy any of this code).
If anyone has any insight on this, it would be greatly appreciated!
Thanks,
Andy
The problem starts with 'dotnet test' command. For some reason, the project with tests can't find a shared library that should be available for it (see a screenshot attached). As you may notice, I'm running the task via Azure DevOps using a custom agent (I think it doesn't really matter). From the logs I realized that the reason it works locally on my machine is that the project I'm talking about is being built in Debug mode in Visual Studio and this is exactly the folder the test project is looking for the library (i.e. \bin\Debug\netstandard2.0\my.dll).
The issue appears when I run 'dotnet test' as a task in the build pipeline in Azure DevOps and the process does not create Debug folder for this exactly project. It's weird, because 'dotnet test' builds solution once again (in the debug mode) and the folder should be generated.
I tried switching the project from 'netstandard2.0' to 'netcoreapp2.2' and adding xunit testing libraries. They're not required in this project but it has started producing Debug folder with compiled libs in it (i.e. \bin\Debug\netcoreapp2.2\my.dll). However, it didn't resolve the issue because the test project still looking for the lib in 'netstandard2.0' folder.
I expect the test projects will be relying on the libs available in Release directory (instead of Debug). Can't get how to achieve this.
You are referencing the DLL in the test project , instead add the reference of the project itself to it.
I'm working on a C# web app running on .net 4.6.1 that assumes that certain dlls are in the same folder as the executing assembly and tries to import some types from those dlls using MEF. That works fine when the app is running and all the required dlls are in the bin folder, but I have problems when running xUnit tests that eventually get to run the code that makes the assumption mentioned above. I'm running the tests using Visual Studio 2017.
The problem I have is that when I run an xUnit test it creates a temp folder which contains a subfolder for each reference I have in my unit test project. In every subfolder there is the .dll and the .pdb file of a single reference along with an __AssemblyInfo__.ini file. Obviously, the test crashes with a FileNotFoundException because the code that wants to import some types using MEF cannot find the dlls in the same folder as the executing assembly location.
Is there a way to tell xUnit to put all the references of the unit test project in a single folder (like the bin folder?) and run the tests using that folder? Or is this maybe a setting in Visual Studio 2017?
You can simply disable shadowCopy, so that all execution uses your output folder.
To learn how to configure xUnit.net via JSON, use a search engine.
I am developing simple Asp.net MVC 5 app which is working ok and visual studio 2015 can build it without any issues, but when i use MSBuild.exe command line tool it shows alot of errors which relates to typescript files compilation (primarily from node_modules folder).
I am trying to use Jenkins CI tool to automate my deployment routine, in order to do so i have to build my app using MSBuild.exe.
My project has tsconfing.json file in the root folder which contains following lines to exclude node_modules folder (it is inside #AngularComponents folder):
"exclude": [ "Scripts/**", "WrittenScripts/#AngularComponents/**" ]
But somehow MSBuild.exe command line tool just ignores it during build.
Does anyone have any ideas how to configure it to take into account my tsconfig? or tell MsBuild to not to build my node_modules folder?
Thank you in advance!
I finally figured it out.
First of all i have to use this MsBuild:
1) C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe;
Secondly, for some reason msbuild messed up my tools version 4.0 so I need to pass additional parameter to msbuild:
2) /tv:14.0
Thirdly, my typescript files have some /// references to node_modules\#types folder and for some reason it shows me any errors but not related to the reference one.
3) so i have to run npm install to recover #types packages.
After these steps msBuild builds successfully without any errors.
Thanks for all!
I have built an installer using WiX that consists of multiple .exe files that are 'Release' builds of other .Net projects (VS 2008). Each time I update one of the projects, I build that project and copy the Release build into the installer and then build and release the installer.
I find it a very tedious job to constantly check if the exe's that the installer has are the latest version or not. Is there a way that I can automate this build process so that as soon as I build the installer, it will generate the latest release builds of the associated projects and place the .exe file in the installer project.
I am new to VS and WiX, please advise. Thanks in advance.
You should be able to create a Solution containing:
- all projects which build the EXEs
- the installer project which builds your installer
Once you are there, you should be able to right click on the Installer Project and set dependencies to all the projects which create your EXEs. You should be able to build your Solution with the right EXEs bundled in your Installer.
Arun's solution is great idea, and I recommend it.
We also have a lot of assemblies that we maintain, and rather than copying them around we use symbolic links to minimize the number of build-and-copy actions. You can research mklink (http://en.wikipedia.org/wiki/NTFS_symbolic_link) for details.
We use it like this, but we do this as part of our environment setup, and not part of our build script.
mklink /project1/bin/project1.dll /project2/bin/project1.dll
This ensures for us that project2's reference to project1 is always up-to-date, whenever project1 is build, without needing to copy the file. In our case, project2 and project1 are not part of the same solution, and they have no direct references to one another (we do a lot of plugin-type reflection/assembly loading).
Hope this helps.