yegoroff / nconfig Goto Github PK

View Code? Open in Web Editor NEW

42.0 42.0 12.0 4.54 MB

Multifile host based cofiguration for .Net

License: MIT License

HTML 4.42% C# 94.76% Batchfile 0.82%

nconfig's People

Contributors

Stargazers

Watchers

Forkers

restuta mxiegit logicbomb leszek-kowalski jamiegaines nikitaegorov lggerard bizon-krzysztof world-direct aegoroff dmitry-baryshev lanicon

nconfig's Issues

Hangup on parsing NHibernate mapping

After replacing system default configuration by NConfig configuration and trying to use the app that has NHibernate mapping the app hangup. Here is stack trace:

0, ntoskrnl.exe!PoStartNextPowerIrp+0x17e7
1, ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
2, ntoskrnl.exe!KeWaitForMutexObject+0x19f
3, ntoskrnl.exe!PoStartNextPowerIrp+0xba4
4, ntoskrnl.exe!PoStartNextPowerIrp+0x1821
5, ntoskrnl.exe!PoStartNextPowerIrp+0x1a97
6, DeviceLockDriver0.SYS+0x2df4d
7, ntdll.dll!NtQueryAttributesFile+0xa
8, KernelBase.dll!GetFileAttributesW+0x78
9, kernel32.dll!GetLongPathNameW+0x7b
10, DomainNeutralILStubClass.IL_STUB_PInvoke(Char*, Char*, Int32) + 0x7b <-- mscorlib.ni.dll+0x54ad8b
11, System.IO.PathHelper.TryExpandShortFileName() + 0xc8 <-- mscorlib.ni.dll+0x4d2c68
12, System.IO.Path.NormalizePath(System.String, Boolean, Int32, Boolean) + 0x53b <-- mscorlib.ni.dll+0x531d3b
13, System.IO.Path.GetFullPathInternal(System.String) + 0x3a <-- mscorlib.ni.dll+0x52788a
14, NConfig.ConfigurationRepositoryWeb.ToAbsolutePath(System.String) + 0x11 <-- 0x7fe97eeb6d1
15, NConfig.ConfigurationRepository.GetFileConfiguration(System.String) + 0x35 <-- 0x7fe97eeb585
16, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x3fa <-- 0x7fe97ef14aa
17, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
18, NConfig.NMultifileConfiguration.GetDefaultSection(System.String) + 0x1e <-- 0x7fe97ef17de
19, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x502 <-- 0x7fe97ef15b2
20, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
21, NConfig.NMultifileConfiguration.GetDefaultSection(System.String) + 0x1e <-- 0x7fe97ef17de
22, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x502 <-- 0x7fe97ef15b2
23, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
24, NConfig.NMultifileConfiguration.GetDefaultSection(System.String) + 0x1e <-- 0x7fe97ef17de
25, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x502 <-- 0x7fe97ef15b2
26, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
27, NConfig.NMultifileConfiguration.GetDefaultSection(System.String) + 0x1e <-- 0x7fe97ef17de
28, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x502 <-- 0x7fe97ef15b2
29, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
30, NConfig.NMultifileConfiguration.GetDefaultSection(System.String) + 0x1e <-- 0x7fe97ef17de
31, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x502 <-- 0x7fe97ef15b2
32, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
33, NConfig.NMultifileConfiguration.GetDefaultSection(System.String) + 0x1e <-- 0x7fe97ef17de
34, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x502 <-- 0x7fe97ef15b2
35, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
36, NConfig.NMultifileConfiguration.GetDefaultSection(System.String) + 0x1e <-- 0x7fe97ef17de
37, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x502 <-- 0x7fe97ef15b2
38, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
39, NConfig.NMultifileConfiguration.GetDefaultSection(System.String) + 0x1e <-- 0x7fe97ef17de
40, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x502 <-- 0x7fe97ef15b2
41, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
42, NConfig.NMultifileConfiguration.GetDefaultSection(System.String) + 0x1e <-- 0x7fe97ef17de
43, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x502 <-- 0x7fe97ef15b2
44, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
45, NConfig.NMultifileConfiguration.GetDefaultSection(System.String) + 0x1e <-- 0x7fe97ef17de
46, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x502 <-- 0x7fe97ef15b2
47, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
48, NConfig.NMultifileConfiguration.GetDefaultSection(System.String) + 0x1e <-- 0x7fe97ef17de
49, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x502 <-- 0x7fe97ef15b2
50, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
51, NConfig.NMultifileConfiguration.GetDefaultSection(System.String) + 0x1e <-- 0x7fe97ef17de
52, NConfig.NMultifileConfiguration.GetSection(System.String) + 0x502 <-- 0x7fe97ef15b2
53, NConfig.NMultifileConfiguration.GetSectionUntyped(System.String) + 0x48 <-- 0x7fe97ef1018
54, System.Xml.XmlConfiguration.XmlReaderSection.get_ProhibitDefaultUrlResolver() + 0x2b <-- System.Xml.ni.dll+0x13f36b
55, System.Xml.Schema.XmlSchemaValidator.Init() + 0x152 <-- System.Xml.ni.dll+0x156eb2
56, System.Xml.XsdValidatingReader.SetupValidator(System.Xml.XmlReaderSettings, System.Xml.XmlReader, System.Xml.Schema.XmlSchemaObject) + 0x9e <-- System.Xml.ni.dll+0x127ade
57, System.Xml.XsdValidatingReader..ctor(System.Xml.XmlReader, System.Xml.XmlResolver, System.Xml.XmlReaderSettings, System.Xml.Schema.XmlSchemaObject) + 0xd6 <-- System.Xml.ni.dll+0x127786
58, System.Xml.XmlReaderSettings.AddValidationAndConformanceWrapper(System.Xml.XmlReader) + 0x8f <-- System.Xml.ni.dll+0x79a165
59, NHibernate.Cfg.Configuration.LoadMappingDocument(System.Xml.XmlReader, System.String) + 0x9d <-- 0x7fe9c8bffbd
60, NHibernate.Cfg.Configuration.AddInputStream(System.IO.Stream, System.String) + 0x59 <-- 0x7fe9c8bfdc9
61, NHibernate.Cfg.Configuration.AddDocument(System.Xml.XmlDocument, System.String) + 0xdc <-- 0x7fe9c93edcc
62, NHibernate.Envers.Configuration.EntitiesConfigurator.Configure(NHibernate.Cfg.Configuration, NHibernate.Envers.Configuration.Store.IMetaDataStore, NHibernate.Envers.Configuration.GlobalConfiguration, NHibernate.Envers.Configuration.AuditEntitiesConfiguration, System.Xml.XmlDocument, System.Xml.XmlElement, System.Type) + 0x4b7 <-- 0x7fe9c9250d7
63, NHibernate.Envers.Configuration.AuditConfiguration..ctor(NHibernate.Cfg.Configuration, NHibernate.Envers.Configuration.Store.IMetaDataProvider, System.Type) + 0x1f0 <-- 0x7fe9c90a430
64, NHibernate.Envers.Configuration.AuditConfiguration.GetFor(NHibernate.Cfg.Configuration, System.Type) + 0x153 <-- 0x7fe9c905dc3
65, NHibernate.Cfg.NhConfigurationExtension.IntegrateWithEnvers(NHibernate.Cfg.Configuration, NHibernate.Envers.Event.AuditEventListener, NHibernate.Envers.Configuration.Store.IMetaDataProvider) + 0x2f <-- 0x7fe9c903d8f

I research the problem and found that NConfig GetSection method are constantly called with parameter value system.xml/xmlReader

Create a NuGet 1.0.19 release and push it to nuget.org

Can you please make a new NuGet release and push it to nuget.org?

Also see: #9

DeepMerger only works for nested collections

Downloaded the latest source. The unit tests around it are not great, or my understanding of what it is capable of doing is incorrect.

The issue is if I have a collection element directly as a child of the section element, then DeepMerger doesn't work. You can see this for yourself with the and elements within the test config files. If you change the GetFiles method to only return one config file (config file 1) instead of all 4 in the yields - those related tests still pass?

If it was correctly merging those collections, then the result of merging test files 1-4 for the ClearCollection element should leave you with ele children with names test1, test2, test3. Instead you get test1,test2,test4 - i.e. the contents of the first test file?

To be clear about what I want to achieve - I simply want to be able to have:
File 1:

<mySection>
  <myObjects>
    <myObject name="Foo" />
  </myObjects>
</mySection>

and File2:

<mySection>
  <myObjects>
    <myObject name="Bar" />
  </myObjects>
</mySection>

Merging should result in being the same as:

<mySection>
  <myObjects>
    <myObject name="Foo" />
    <myObject name="Bar" />
  </myObjects>
</mySection>

An additional problem with DeepMerger - it doesn't work with App.config files. So in my example above, if File 1 is my App.config, and File 2 is MyCustom.config, and I attempt to merge with UsingFile("MyCustom.config") then the DeepMerger throws an exception saying that the configuration is read-only. UPDATE - I solved this by overriding IsReadOnly on the ConfigurationElement.

Finally yet another issue with it is it doesn't support the element, just gets ignored.

NullReferenceException on Windows 10 insider build 15002rs

Currently I'm on insider build of Windows 10 - 15002rs

Registry says that I have .Net 4.7.02020 version installed

Here is a stack trace:

[NullReferenceException: Object reference not set to an instance of an object.]
   NConfig.ReflectionAccessor.PropertyGetterFunc(String name) in c:\Projects\ThirdParty\NConfig\NConfig\Implementation\System\ReflectionAccessor.cs:147
   NConfig.<>c__DisplayClass4`2.<Memoize>b__3(TArg a) in c:\Projects\ThirdParty\NConfig\NConfig\Util\MemoizeExtensions.cs:40
   NConfig.ReflectionAccessor.GetProperty(String name) in c:\Projects\ThirdParty\NConfig\NConfig\Implementation\System\ReflectionAccessor.cs:65
   NConfig.NWebSystemConfigurator.SubstituteSystemConfiguration(IConfigurationFactory factory, IList`1 fileNames) in c:\Projects\ThirdParty\NConfig\NConfig\Implementation\System\Web\NWebSystemConfigurator.cs:40
   NConfig.INConfigurationExtensions.SetAsSystemDefault(INConfiguration config) in c:\Projects\ThirdParty\NConfig\NConfig\INConfiguration.cs:139

Debugging shows, that there is no CacheInternal property n System.Web.HttpRuntime anymore.

System.Web.dll.zip

NConfig breaks with System.Web update on Windows 8.1

Yesterday there was an update on Windows 8.1 which modified the System.Web dll.
There was a change in private fields System.Web.Caching.CacheMultiple
It used to have a private field "_caches" and now it has a private field "_cachesRefs"

NConfig crashes with a null reference exception.
ReflectionAccessorcs line 113

Check NWebSystemConfigurator.UpdateCacheMultiple
line 57 where it gets the value of the _caches field.

Pretty scary stuff that a Windows update can break our apps. What happens when this update is applied to the Windows Azure servers? Our apps might break big time.
NConfig should not reply on these private fields, but I guess it's needed somehow to work.

Build with VS 2017

For compiling, I had to make two changes and there is an issue concering one unit test:

First, I had to install NUnit TestAdapter Nuget package for supporting Visual Studio 2017. I will create a Pull Request later.

Second, I had to change the nuget.config file to contain instead of .

Third, the test "Should_convert_passed_relative_paths_to_absolute_correctly" fails always. I am not quite sure why it might have changed. It fails in VS 2015 as well.

MFG (sincerly)
HeikoStudt

overriding ELMAH settings

I'm trying to override the elmah settings in a machine specific config and not having any luck. Is this supported?

Release version 1.0.17 containing PR #6

Hello,

I would like to use the functionality added by PR #6 Could you release this code to nuget? Thanks in advance!

Upgrading the project for VS 2017

If all contributors of NConfig are able to upgrade to VS 2017, it has a new type of project file which is able to "pack" Nuget packages directly, without special build steps or some batch script. It can even create multi-target nuget packages easily, handling special nuget dependencies for each etc.

Though there are quite some bugs/crashes involved while migrating, I propose to do so.

MFG (sincerly)
HeikoStudt

"Copy To Output Directory" setting requires file to be added to solution

In the documentation, it recommends setting Copy To Output Directory = Copy Always for each config file so that they are copied to the output directory. But doesn't this miss the whole point of using NConfig? The idea is that the config file does not necessarily exist. That way, I can provide the file on my developer system but not provide it on the live system so it falls back to Web.config. More importantly I can exclude the developer config files from source control so that developer passwords etc. are not checked in. This means I don't want to add these config files to the solution. But in order to have the Copy To Output Directory setting available, I have to add the config file to the solution. Is this not a contradiction?

Strong naming

Like what this does (well done), however... why do you not strong name NConfig, like pretty much every other distributed library does? We have to download the source and rebuild it manually with a strong name each time, rather than just being able to reference the NuGet package?

Also why does the 1.1.21 package on NuGet.org not contain the Net35 build, only the Net40 one?

Compilation error in MVC5

Can't make NConfig work in my MVC app. I initialized the NConfig:

protected void Application_Start()
        {
            NConfigurator.UsingFile("Local.config").SetAsSystemDefault();

And it works OK when I invoke controller's method which returns string:

public string ConfigName()
{
  return ConfigurationManager.AppSettings["name"];
}

However, when a method returns ActionResult I see Compilation Error. This method:

        public ActionResult Index()
        {
            var appSetting = ConfigurationManager.AppSettings["name"];
            return View((object) appSetting);
        }

results into this error message when I try to open the page:

I've already tried everything I found in google about such message, but I still can't get it work. And I can't imagine how could it be related to your lib, but removing NConfig initialization (or putting a non-existent filename there) solves everything.

Project state?

It looks like a great tool, is the project abandoned? Does anybody use it in production code?

ConfigurationRepository has a cache - why?

Hi,

currently, Implementation/ConfigurationRepository.cs is statically used by NConfigurator.config.
ConfigurationRepository.cs caches files so they are parsed only once. You cannot flush this cache.

By this, you cannot reload your merged configuration without restarting your application.
Currently there is an IO-Operation (File.Exists) within the repository - this is counter-intuitive, as all other changes to the file are ignored.

I propose the removal of the file-cache.
For the performance-argument: as the merging of the configuration files is already quite costly, at least while using DeepMerger. We should focus on caching the resulting (merged) configuration instead or let the user decide whether to cache alltogether.
At least in our applications we are caching the merged sections, because as the (Deep-)Merger is called for each GetSection() that calculation is in itself a massive performance-drainage.

MFG (sincerly)
HeikoStudt

yegoroff / nconfig Goto Github PK

nconfig's People

Contributors

Stargazers

Watchers

Forkers

nconfig's Issues

Recommend Projects

Recommend Topics

Recommend Org