I am using NHibernate in a DAL layer dll. Local config file(app.config) is being used for db connection. This DAL component can be used in 2 different exe's and a NUnit test harness. Business requirement from Client is to have config information reside in exe's app.config file.
Is there a way to configure NHibernate to look for an app.config file based on the exe that it is compiled with?
Then in the NUnit test harness, look for a default config file?
Thanks,
Marc
As Dan hinted, NHibernate's main config section can either be in a standalone hibernate.cfg.xml, OR it can be put in the application's config file. If you want NHibernate's core config to vary by the currently executing environment (different apps, or during testing), you can go the app.config route. If no hibernate.cfg.xml file is found, NHibernate is going to look in the currently executing app's app.config file.
Here is an example of putting the NHibernate config in an app.config file: http://www.martinwilley.com/net/code/nhibernate/appconfig.html
Related
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.
In our WCF solution we have one ConsoleHost (console application not class library) project and one WasHost Project. We use the Consolehost hosting for Dev environment and WAS hosting for production.
Now there are a number of .config files that are included using "include uri=file://services.config" in the Castle section of ConsoleHost project. I don't want to make a copy of this services.config file in the WasHost Project.
Is there a way to include files from other projects without making local copies of them? Or happy to hear other better ways of doing this.
Thanks
Ravi
You could do this a couple of ways.
One is to simply add a link to the source file from both projects as described here.
Alternatively you could embed the config into one of the common assemblies (Build Action=Embedded Resource in the file properties) and then use Castle's ability to include embedded resources. E.g.
<include uri="assembly://AssemblyName/xxx.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 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.
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.