Microsoft's instructions on EF configuration files show this example.
<databaseInitializer type="System.Data.Entity.MigrateDatabaseToLatestVersion`2[[Blogging.BlogContext, MyAssembly], [Blogging.Migrations.Configuration, MyAssembly]], EntityFramework" />
What is the meaning of the `2 in the config file?
The MigrateDatabaseToLatestVersion has two type params.
From msdn:
When we create an instance of this initializer we need to specify the
context type (BlogContext) and the migrations configuration
(Configuration) - the migrations configuration is the class that got
added to our Migrations folder when we enabled Migrations.
So, that's why there's the `2 in the configuration file.
Related
I recently read that it is possible to define the Log4Net Config XML in defining this file in a class attribute.
<Assembly: log4net.Config.XMLConfigurator(ConfigFile:="Log4Net.Config.xml", Watch:=True)>
How can I define this file using only pure VB.Net code without using Attribute technique ?
Example (this is only textuals examples)
log4net.Config.OpenFile("Log4Net.Config.xml")
log4net.OpenConfigFile("Log4Net.Config.xml")
log4net.InitLoggingConfigFile("Log4Net.Config.xml")
The configuration's file already exists.
I search only the code that read it to configure logging.
To solve your issue, you can use XmlConfigurator.Configure() function
XmlConfigurator.Configure(new System.IO.FileInfo(args[0]));
that is explained on Apache Net4Net site
I have a nuget.config file (in my asp.net core project) which points to a local share on our company network for custom nuget packages.
However, when I am working from home, that address is not available.
I can see a number of options, including...
create an environment variable for the reference to our local feed
host the packages in azuredevops
have a custom nuget.config files
But ideally I'd like a zero config solution which I can check into source control. Something like adding a packageSource with an "optional" attribute and let dotnet restore figure out where it can get packages from. But there isn't an optional attribute and dotnet restore fails if it can't connect to the package source.
Is a zero config solution possible?
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.
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
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.