I using unit testing, to ensure that I can read connect string information from the ConnectStrings section of my app.config file. This works fine in the application proper, However when I attempt to generate a unit test for this under the Test Project, the dll.config file is being ignored, and the connectstring info from the machine.config file is being retrieved instead. How do I ensure that my tests read from the correct config file?
Your test project must have its own App.Config file.
You should add an app.config file to to your test project and populate it with the necessary values. You may ask "Why can't I use the existing app.config in my project?" The real answer is probably out there but personally I like it this way because it means my test project never points at my production environment.
Related
I've bene doing well with .NET config transforms. I have them in place now on a class library for data usage and a WPF app.
However, when I attempt to set them up with an ASP.NET WebAPI project, something strange seems to happen.
The config file never shows up in my bin directory, and so the web.config always shows as the pre-formed config file.
If I run MSbuild with parameters of "/t:TransformWebConfig /pConfiguration=Test" on the csproj, I see the following:
CollectWebConfigsToTransform: Found The following for Config
tranformation: Areas\HelpPage\Views\Web.config, Web.config,
Views\Web.config, bin\Web.config PreTransformWebConfig: Skip copying
Web.config to obj\Test\TransformWebConfig\original\Web.config, File
obj\Test\TransformWebConfig\original\Web.config is up to date Skip
copying C:\Users\killesj1\Repositories\MRP Trunk\Macro
Projects\VEUploader\src\app\VEUploader.WebAPI\Web.config to
obj\Test\TransformWebConfig\original\bin\Web.config, File
obj\Test\TransformWebConfig\original\bin\Web. config is up to date
TransformWebConfigCore: Skipping target "TransformWebConfigCore"
because all output files are up-to-date with respect to the input
files. TransformWebConfigCore: Skipping target
"TransformWebConfigCore" because all output files are up-to-date with
respect to the input files. PostTransformWebConfig: Transformed
Web.config using Web.Test.config into
obj\Test\TransformWebConfig\transformed\Web.config. Transformed
C:\Users\killesj1\Repositories\MRP Trunk\Macro
Projects\VEUploader\src\app\VEUploader.WebAPI\Web.config using
C:\Users\killesj1\Repositories\MRP Trunk\Macro
Projects\VEUploader\src\app\VEUploader.WebAPI\Web.Test .config into
obj\Test\TransformWebConfig\transformed\bin\Web.config.
It appears that the transformation is tranforming the file, but somehow it's not making its way back into the bin directory, where the old Web.config remains.
Is this normal? How might I get this to behave similarly to other web transforms?
I had a similar problem, deploying Test projects on Appveyor that weren't being transformed, and followed the advice in the link below and now everything works nicely. I had all my projects set up to do xxx.config transforms in the [Target Name="AfterBuild"] and it worked perfectly on my local dev machine, but on pushing the code to Appveyor, the tests would fail because of untransformed files etc. Basically, move everything to the [Target Name="BeforeBuild"] and see if that helps.
MSBuild - how to force "AfterBuild" target when I do deployment?
web.config normally located in the root and is not copied to bin subfolder. To apply transforms you need to have some template web.config and transform it to root web.config.
E.g. see https://stackoverflow.com/a/16239488/52277 and Use Visual Studio web.config transform for debugging
I just inherited a VB.Net application that gets a SQL connection string like this:
Dim m_GMSConnString As String = System.Configuration.ConfigurationSettings.AppSettings("connString")
But there's no app.config file in the solution/project. So where is it reading from?
EDIT: If this is a DLL project and the DLL is then referenced by a website project, will the DLL read from the web.config of the website project? That's the only explanation I can come up with.
EDIT: If this is a DLL project and the DLL is then referenced by a
website project, will the DLL read from the web.config of the website
project? That's the only explanation I can come up with.
From my experience (and it is confirmed here Why wont my application read my MyApplication.dll.config file?) answer is yes, the code will only read the app.config of the main project (or web.config in your case).
But the answer also provides link that show how to use multiple config file. I think you can tell your program to read some part from external file (your dll.config file in your case).
if I remember correct, there is a config file with the same name as the exe file but add the extention of .config, such as yourprog.exe.config
I'm very new to MSpec and BDD in general and are currently having trouble having mspec pass a Search class that looks up employee data via an XML feed. The parameters for the url are held in an app.config file and seems as if the app.config is not being accessed to obtain the config setting.
Otherwise mspec is running fine for all other tests so far its just this one particular.
How do I write a test to utilise or mimic if thats needed, for the config file access please ?
Thanks
You probably have app.config in your production code project (project which is being tested), try adding the same app.config in Tests (project with MSpecs).
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...
I have inherited a project that has class libraries written in VB.NET, some of these have ".settings" files and the others have a ".dll.config" file to store connection strings. What is the difference between these 2 methods?
EDIT: In what scenarios would I prefer one over the other?
They're basically the same thing - or strongly related, anyway. A settings file gives you strongly-typed access to entries in an app.config file, and keeps them in sync. When you compile, the app.config file is copied to the bin folder with the name of your assembly.
Note that, if you modify the .config file by hand, you can lose changes if the settings file overwrites them. In VS2008 it will prompt you, so you can choose to sync them.
I think that .settings is application wide, while the .dll.config files are specific to the assembly they are named for.
".config" files are at the core of .NET configuration system. They store the actual configuration data. In the early .NET framework, if you wanted to extend the configuration system to handle your custom configuration data, you had to do this manually. "Settings" file is a feature that allows you to visually define configuration options and use them to create a strongly typed class. This class can then be used as a method to read and manipulate the configuration data specified in application's ".config" file at runtime. They also provide some neat features automatically, such as defining per-user or per-application configuration options. They greatly reduce the hassle to manually extend the configuration system.