NUnit not reading the configuration file - vb.net

I have written a NUnit tests for a .NET application. When I run the NUnit, it does not read the connection string values from the configuration file. I tried many solutions with out success, like
Adding <assembly name>.dll.config file in the path where NUnit loads the DLL file.
Adding the configuration settings in NUnit.exe.config/NUnit.gui.config
I wasn't able to read the configuration setting even when run in VSNunit. Is there a solution?

I've assumed
Assembly being tested: SomeNameSpace.MyClassLib
NUnit assembly with unit tests: SomeNameSpace.MyClassLib.Test
Try this:
Make sure that you have also copied your app.config to your NUnit Test DLL class library (i.e. project SomeNameSpace.MyClassLib.Test) as well.
Build your NUnit Project (e.g. to SomeNameSpace.MyClassLib/bin/debug) and make sure that following are in the bin\debug (or release) directory
the assembly to be tested,
the NUnit test DLL and
the configuration (SomeNameSpace.MyClassLib.Test.config)
any other assemblies needed by your DLL file being tested.
Edit your NUnit Project in the XML view of the NUnit GUI Project editor (menu Project → Edit, or just edit it in Notepad), and make sure that the test assembly (MyClassLib.Test.dll) and the configuration file names are relative to your appbase
For example,
<NUnitProject>
<Settings activeconfig="Debug" processModel="Default"
domainUsage="Default"
appbase="C:\Temp\MyProject\MyClassLib.Test" />
<Config name="Debug" binpathtype="Auto"
configfile="bin\Debug\MyClassLib.Test.dll.config">
<assembly path="bin\Debug\MyClassLib.Test.dll" />
</Config>
<Config name="Release" binpathtype="Auto" />
</NUnitProject>

Add an app.config file to the test project and add your configurations in there.
You then have to tell NUnit what configuration to use as by default it will not pick up the app.config file.
More information on how to set this up with screenshot.

I was stuck on a similar issue for a while. We also need to look at how you are loading the assemblies, based on that the naming of configuration file changes (unless you are using an explicit configuration file from settings). As mentioned here:
http://www.nunit.org/index.php?p=configFiles&r=2.2.10
If a single assembly is being loaded, then the configuration file is given the name of the assembly file with the config extension. For example, the configuration file used to run nunit.tests.dll must be named nunit.tests.dll.config and located in the same directory as the DLL file.
If an NUnit project is being loaded, the configuration file uses the name of the project file with the extension changed to configuration. For example, the project AllTests.nunit would require a configuration file named AllTests.config, located in the same directory as AllTests.nunit. The same rule is followed when loading Visual Studio projects or solutions.

Related

What is the difference between specifying a dependentAssembly in app.config and reference a dll in a .net project?

I have a .NET windows service made in VB.NET in Visual Studio 2013. In this project I have some DLLs referenced and also in app.config I have others defined as dependentAssembly (I didn't make this project).
When I compile this project, dependent assemblies specified in app.config are not being copied to output directory (debug or release depending on the case).
My questions are:
What is the difference between specifying dependent assemblies in app.config and reference a DLL?
Why dependent assemblies specified in app.config are not being copied to the output directory (debug or release) when compiling?
Can I force visual studio to copy dependent assemblies specified in app.config to outut directory (debug/release) when compiling?
Here is the relevant information I found about dependentAssembly. App.config should not be used on dlls, but only with executables.
If a dll is loaded in an executable, the dll will use the configuration file of the running executable and will ignore the configuration defined for him.
If you like, you can read the configured keys using some ugly code that takes them from the configuration file for the current assembly.
What you should do is put the relevant configuration into the exe configuration file. You can checked in this link for more details.

MSBUILD Dynamically Create Config XML Dotfuscator

I am trying to obfuscate bunch of files in a directory and every build there are more and more files being generated. I would like to know if there is a way I can dynamically create the Dotfuscator configuration xml file using a MSBUILD task that will generate the xml file every time there is a new file added to the directory?
This might be a good time to use the Directory input. Rather than representing a single assembly (.exe or .dll), this type of Dotfuscator input captures all the assemblies in a directory. When the contents of the directory change, Dotfuscator's build will automatically pick up any new assemblies.
To make a Dotfuscator config file with a Directory input, open the GUI and add an input as you normally would (directions for Community Edition's GUI and for Professional Edition's standalone GUI), but instead of selecting a file from the Browse... dialog, just navigate to the directory and click "Open" while the "File name" is still listed as "Folder Select". Then, save your configuration.
From now on, whenever you run Dotfuscator (whether from the standalone GUI, the command line, the Visual Studio integration, or the MSBuild task), all assemblies in the directory will be processed as input.
Note: If you look at the config file itself, you might be surprised that it will still list individual assemblies:
<input>
<loadpaths />
<asmlist>
<package refid="19e1b0c5-7221-476f-af4b-bafef68edc95">
<file dir="C:\code\BasicTestApp\BasicTestApp\bin" name="Debug" />
<asmlist>
<inputassembly refid="a6da5d8d-c181-4103-840d-d8cc7c85937a">
<option>honoroas</option>
<option>stripoa</option>
<option>transformxaml</option>
<file dir="" name="BasicTestApp.exe" />
</inputassembly>
<inputassembly refid="df84dad0-fbe8-49ab-b8c8-9fb59e706785">
<option>honoroas</option>
<option>stripoa</option>
<option>library</option>
<option>transformxaml</option>
<file dir="" name="ClassLibrary.dll" />
</inputassembly>
</asmlist>
</package>
</asmlist>
</input>
Despite this layout, Dotfuscator will process all assemblies in the C:\code\BasicTestApp\BasicTestApp\bin\Debug directory when it runs a build based off this config file, not just those two listed.
The assembly elements in the config are just there so that you can still make rules against individual assemblies in the GUI (e.g., to make one assembly be in Library Mode).
The list represents the state of the directory when the GUI last modified the config.
Disclaimer: I work for the Dotfuscator team, and am answering this question as part of my job.
Additional note due to clarification in the comments: the directory package has a feature where you can exclude certain assemblies from obfuscation. These assemblies will be treated as a Package Artifact and just copied from input-to-output without modification. Any obfuscated assemblies that refer to these excluded assemblies will still be processed correctly.
To do this in the GUI, right-click on the assembly within the package, and select "Exclude assembly from package". Or, if you'd prefer to edit the config file, add the following <option> tag as a child of each relevant <inputassembly> tag:
<option>artifact</option>
The latest Dotfuscator version 4.41.1 has the latest flag
true
This will generate the Dotfuscator config file if the file is missing. Also you can add this to the csproj as documented in the latest getting started guide https://www.preemptive.com/dotfuscator/pro/userguide/en/getting_started_protect.html

How do I embed StyleCop in the solution?

I try to integrate StyleCop in a Visual Studio solution. Installing StyleCop on each machine of each developer is something I would prefer to avoid. The suggestion I've seen several times (example) is to include the binaries of StyleCop within the project, storing them in version control.
I did that. It works on my machine, but fails on a different machine where StyleCop is not installed. After uninstalling StyleCop on my machine, it doesn't work there either.
The error message is the following:
Severity Code Description Project File Line
Error The "StyleCopTask" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild..\StyleCop 4.7\StyleCop.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\StyleCop 4.7\StyleCop.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. Demo
This is what I included in every .csproj file:
<Import Project="$(SolutionDir)\externs\Microsoft.StyleCop\StyleCop.targets" />
The directory C:\demo\externs\Microsoft.StyleCop contains:
The copy of all the files from C:\Program Files (x86)\StyleCop 4.7,
The copy of C:\Program Files (x86)\MSBuild\StyleCop\v4.7\StyleCop.Targets.
What's wrong?
It appears that StyleCop.Targets contains an absolute path:
<UsingTask
AssemblyFile="$(MSBuildExtensionsPath)\..\StyleCop 4.7\StyleCop.dll"
TaskName="StyleCopTask"/>
In order to be able to use StyleCop on machines where the application is not installed, change this path to something similar to:
<UsingTask
AssemblyFile="$(SolutionDir)\externs\Microsoft.StyleCop\StyleCop.dll"
TaskName="StyleCopTask"/>

Unable to build solution incrementally: Input file ".NETFramework,Version=v3.5" does not exist

I'm not able to build solution incrementally. I checked diagnostic log and I found that every project containing workflows are always rebuild because of this:
Input file ".NETFramework,Version=v3.5" does not exist.
Workflows are always recompiled, new temporary files are created and project is build again.
Building target "WorkflowCompilation" completely.
Input file ".NETFramework,Version=v3.5" does not exist.
Using "CompileWorkflowTask" task from assembly "System.Workflow.ComponentModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35".
Task "CompileWorkflowTask"
No files found with '.xoml' extension in the set of input files.
Generated temporary code file: C:\Users\Ludwo\AppData\Local\Temp\uwdnm5th.cs
Workflow markup validations completed with 0 errors and 0 warnings.
Done executing task "CompileWorkflowTask".
Done building target "WorkflowCompilation" in project "Delta.Workflow.Common.Merged.csproj".
Target "CoreCompile" in file "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.CSharp.targets" from project "h:\Prj\R4x\M\CountrySystems\Delta\Common\Delta.Workflow.Common\Delta.Workflow.Common.Merged.csproj" (target "Compile" depends on it):
Building target "CoreCompile" completely.
Input file "C:\Users\Ludwo\AppData\Local\Temp\uwdnm5th.cs" is newer than output file "obj\Debug\Delta.Workflow.Common.pdb".
I'm building my projects using MSBuild 4.0. My projects are set to build with v3.5 TargetFrameworkVersion, unit tests projects are build with TargetFrameworkVersion set to v4.0. I tried to build it on different PC but the result is still the same. I also played with references in my projects. It seems to be like v4.0/v3.5 conflict, but I don't know how to fix it. Any ideas?
I found it. The root cause is wrong version of Workflow.targets file imported inside my workflow (.csproj) projects. Workflow.targets for .NET v4.0 was imported instead of v3.5. It should be related to projects upgrade from VS2008 to VS2010 I did some time ago.
I changed Workflow.targets Import from
<Import Project="$(MSBuildToolsPath)\Workflow.targets"/>
to
<Import Project="$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.targets" />
Hope it helps someone...

MSBuild - trying to run xUnit (.net) tests

I'm trying to set up a C# project that'll run xUnit tests when I build, so I can use them in continuous integration. I have a regular project, a class library test project using xUnit, and my test runner project. From everything I've read, it appears that I should be able to get this working by doing this in the test runner project:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Test"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
[auto-created project stuff]
<UsingTask AssemblyFile="xunit.runner.msbuild.dll"
TaskName="Xunit.Runner.MSBuild.xunit" />
<Target Name="Test">
<xunit Assembly="$(MSBuildProjectDirectory)\..\OnePageOneDb.Tests\bin\Debug\OnePageOneDb.Tests.dll" />
</Target>
</Project>
When I build my solution after a change (usually editing the .csproj file), I get this:
The "Xunit.Runner.MSBuild.xunit" task
could not be loaded from the assembly
C:\Users[myusername]\Code\OnePageOneDb\OnePageOneDb.TestRunner\xunit.runner.msbuild.dll.
Could not load file or assembly
'file:///C:\Users[myusername]\Code\OnePageOneDb\OnePageOneDb.TestRunner\xunit.runner.msbuild.dll'
or one of its dependencies. The system
cannot find the file specified.
Confirm that the
declaration is correct, that the
assembly and all its dependencies are
available, and that the task contains
a public class that implements
Microsoft.Build.Framework.ITask.
Even if I add xunit.runner.msbuild.dll and xunit.runner.utility.dll to the project in the location it refers to, I get this message. But if I build again with no changes, I consistently get this:
The "xunit" task was not found. Check
the following: 1.) The name of the
task in the project file is the same
as the name of the task class. 2.) The
task class is "public" and implements
the Microsoft.Build.Framework.ITask
interface. 3.) The task is correctly
declared with in the
project file, or in the *.tasks files
located in the
"C:\Windows\Microsoft.NET\Framework\v4.0.30319"
directory.
But I've checked all these things:
The task class in xunit.runner.msbuild.dll is Xunit.Runner.MSBuild.xunit (and xunit is lowercase in the class name).
The task class inherits from Task, which implements ITask.
So maybe there's a problem in UsingTask, but I don't know what it is.
(I also thought the problem might be that xunit.runner.msbuild.dll is targeted at .NET 2.0, and I'm using VS 2010, but I recreated the test runner project in .NET 2.0 and the problem persisted.)
Can anyone help?
You need to specify correct path to xunit.runner.msbuild.dll.
First of all, you can just set the full path and test that xunit just works as you want.
But for real environment you should specify relative path to the dll.
<UsingTask AssemblyFile="$(MSBuildProjectDirectory)\..\..\lib\xunit\xunit.runner.msbuild.dll"
TaskName="Xunit.Runner.MSBuild.xunit" />
MSBuildProjectDirectory is a reserved property and contains "the absolute path of the directory where the project file is located".
EDIT:
Try to use target by full name Xunit.Runner.MSBuild.xunit
<Target Name="Test">
<Xunit.Runner.MSBuild.xunit Assembly="$(MSBuildProjectDirectory)\..\OnePageOneDb.Tests\bin\Debug\OnePageOneDb.Tests.dll" />
</Target>
I get exactly the same error message if I have Pex and Moles installed. Everything works fine after uninstalling them.
By default building in "release" configuration triggers running xunit tests.
If you are trying to disable running xunit tests in tfsbuild pass the following build parameter.
This can be useful in the new cross platform builds where running unit tests is a separate step.
/p:RunXunitTests=false