How to use app.config file with mstest.exe in cruise control - msbuild

I am using mstest.exe for executing my test cases, when i run this test cases from vs they run fine, but when i run them from cruise control using ms-build they give me exception that they are not able to read application.config.
I mean i have created a class that reads value from app.config.
It has a field that read port number as a string and convert it to int, with VS it is working file, but with Ms build it show exception that ArgumentNullException.
So how can i specify that mstest use specific app.config file.
Thanks in advance.

On the app.config properties, set Copy to Output Directory=Copy always
If the tests run under the TestDeploymentDir use the DeploymentItemAttribute:
[TestMethod]
[DeploymentItem("app.config")]
In Visual Studio 2012 or newer you can use .runsettings for more deployment options.
In Visual Studio 2010:
From the Test menu > Edit Test Settings > Local > Deployment tab > check Enable deployment and Add file and point the app.config

Related

Unable to get Visual Studio Online to execute my nUnit tests

I have a solution with a number of nUnit tests that do not appear to run on Visual Studio Online servers. Here's what I've done so far:
Created a separate folder (outside of my branch structure) that has nUnit test adapter DLLs
Build controller is configured with a path to custom assemblies to point to nUnit folder that has adapter DLLs
Build's test Source is configured as:
" - Run tests in test sources matching *test*.dll;*test*.appx,Target platform: 'X64'"
Build controller reports during the build
Run optional script after MSBuild
Run optional script before Test
Runner Run VS Test Runner
Run Continuous Deployment
No test results afterwards.
No test results
No code coverage results
What am I doing wrong? Do nUnit tests require special attributes to run properly on VSO? Am I missing any other configuration settings?
I've followed this link when configuring: http://www.visualstudio.com/get-started/hosted-build-controller-vs#supplemental_binaries
Edit:
Test settings expanded as requested
Appreciate any help!
Well, I never setup a TFS build before, let alone an online one, until now (TeamCity fan), so I copied every single property from the screenshots and the only way I could get it to pseudo-"pass" (fully green, with no No test found. Make sure that installed test discoverers & executors warnings under Other Errors and Warnings) is when it didn't find any *test*.dll assemblies to load to begin with, rather than no [Test] methods to execute. Did you check your MSBuild log to make sure your test project assemblies are copied and match the pattern?
_CopyFilesMarkedCopyLocal:
Copying file from "C:\a\src\Alertera-Scheduler\packages\NUnit.2.6.3\lib\nunit.framework.dll" to "C:\a\bin\nunit.framework.dll".
Copying file from "C:\a\src\Alertera-Scheduler\packages\NUnit.2.6.3\lib\nunit.framework.xml" to "C:\a\bin\nunit.framework.xml".
CopyFilesToOutputDirectory:
Copying file from "obj\Debug\Alertera-Scheduler.Tests.dll" to "C:\a\bin\Alertera-Scheduler.Tests.dll".
Alertera-Scheduler.Tests -> C:\a\bin\Alertera-Scheduler.Tests.dll
Copying file from "obj\Debug\Alertera-Scheduler.Tests.pdb" to "C:\a\bin\Alertera-Scheduler.Tests.pdb".
Done Building Project "C:\a\src\Alertera-Scheduler\Alertera-Scheduler.Tests\Alertera-Scheduler.Tests.csproj" (default targets).
Done Building Project "C:\a\src\Alertera-Scheduler\Alertera-Scheduler.sln" (default targets).
Could you expand your Test source settings as well?
If you click Open Drop Folder (Build details in VS) > Diagnostics (tab in VSO) what does it say under Run VS Test Runner?
Run VS Test Runner 00:00:00
There were no matches for the search pattern C:\a\bin\*test2*.dll
There were no matches for the search pattern C:\a\bin\*test*.appx

Loading specific test file for debugging MSProject Add-In

I am developing a MSProject add-in with VSTO and I have a question about debugging.
How do I use the Start Option->Command line arguments to load a specific MS Project file?
I have tried using [drive:][path]filename.mpp but the file doesn't load.
Otherwise everything is fine. I can load a file manually and debug properly.
Thanks for any assistance.
You can use the following command line example to load MS Project with a specific MPP file:
winproj "c:\projects\Annual Report Preparation.mpp"
For Visual Studio Project->Debug->Start Options->Command Line arguments - you can use the path enclosed in quotations. The gotcha here is that you must also assign the Start Action->Start External program for this to work - this is a VS bug.
"c:\projects\Annual Report Preparation.mpp"
Use ... and set Start External Program (depending on your Office version):
C:\Program Files (x86)\Microsoft Office\Office15\WINPROJ.EXE
See MS Office for further MS Project command line reference.

Include an XML file in the Project Build

I have written a small VB.NET simulation program that uses an XML file to configure the simulation. I want to include this file in the project build so that when the application is installed, there will be a default XML file in the required directory.
When I do the Project Publish (within VB 2010 Express), there is no option for including any extra data files in the process.
Is it possible to do this with VB 2010 Express ... or should I try some other project builder/installer.
Any pointers will be very much appreciated,
Regards,
Oliver
The option isn’t found in the publisher, it’s a property of the file itself: when you add a file to the project you can set its file properties in the property window (usually at the right-hand side of the screen, below the file browser).
There you can set its “Build Action” to “Content” and its “Copy to Output Directory” mode to “Copy if newer”.

Output directory when building a WCF project in Visual Studio

I have a Visual Studio 2010 solution that is set to build in Debug x86. Visual Studio therefore sets the output path to \bin\x86\Debug, which seems logical enough.
The solution contains about 50 projects; the start-up project is a WCF project.
When I do a build, I would expect all output dlls to go to \bin\x86\Debug, as that is what is set in the project settings. But weirdly, I see dlls being created in bin\x86\Debug and in \bin. Why would Visual Studio put any dll in \bin if the output path is not set to that directory? It seems that all dlls go to \bin\x86\Debug, and all dlls except for the start-up project go into \bin. Any idea why it would do that? (We have other solutions that don't use WCF, and they don't have this problem.)
The other annoyance is if I run the service from Visual Studio and then try to access my service in a web browser, by going to http://localhost:1240/MyService.svc, it doesn't work, because the start-up project dll is missing from /bin. I therefore have to manually copy this one dll from \bin\x86\Debug to \bin, so that all dlls are found and the service runs normally. (We could of course add a custom post-build step that does the copy, but you'd think there'd be a better way!)
To those of you working on WCF projects, do you leave the output path at \bin\x86\Debug? (Perhaps there is a way to configure the service, eg in the web.config or .svc file, so that it knows the binaries are in \bin\x86\Debug instead of \bin?) Or do you change the output path to \bin so that you can run your service straight from Visual Studio?
If you open the property page of you WCF Hosting project and goto tab Build, under the Output section of this tag there is a textbox that contains the location of the output binaries.
For a WCF project the binaries should go to bin directory irrespective of the build type (suc as Debug, Release). Make sure this value has been configured correctly.
The value needs to be configured for each build type\configuration.
If you need, for whatever reason, different outputs from different build configurations in different folders you could specify them like you did first and use a post build event command line that copies from your specified output folder to bin.
Like:
- untested code -
COPY/Y "$(OutDir)\*.*" "$(SolutionDir)$(ProjectName)\bin\"
- untested code -

WcfSvcHost.exe not running when I debug a Wcf Library

I have WCF library project which I have recently done some minor refactoring on eg changing the namespace and changing it location on disk. I also removed the app.config, because I thought the app.config is used by whatever hosts the wcf service.
I have since noticed that I can no longer debug the library using the WcfSvcHost like I used to be able to do. The message I get from Visual Studio is:
'A project with an Output Type of Class Library cannot be started directly.
In order to debug this project, add ana executable project to this solution which references the library project. Set the executable as the startup orject.
I don't want to do as it says, because I didn't need to do this before. Please let me know how to restore the ability to debug it using the WcfSvcHost. On the Debug tab of the project settings, the Command line arguments is still set to: /client:"WcfTestClient.exe"
Not sure what else to try, thanks.
I have observed that changing the output path of the project cause this behavior. To re-enable the debugging using WCFSvcHost/WCFServiceClient leave the output path to default and it should work.
If you changed the project output path you can still run it, you just need to provide some extra parameters to WcfSvcHost like this (enter this in Command Line Arguments in project's debug settings):
/service:ServiceInterface.dll /config:application.config /client:"WcfTestClient.exe"
No need to enter the full path as it will be run from your new project output path
If you still get the 'A project with an Output Type of Class Library cannot be started directly' then you can try changing the start action to 'Start external program' and select the WcfSvcHost.exe in there
You need to build the project in Debug Mode in order to use WcfTestClient and WcfSvcHost
In Debug mode you don't need another project. The Wcf Service Library runs in WcfSvcHost
However if your solution has only Wcf Service Library you need the app.config to configure the endpoints and etc...