Hi all,

I've a simple question: Is it a way to enable "autoDependencyInjectionDiscovery" without modifying the config file ?

Because we have our own config system, and when updating an installation we don't touch the .config file as it's a pain to merge old and new config...

So my problem come from existing customer, when they will updated to the new version of application (using DI), I don't want to modify the config.

Any idea ? Tx

No way unless you want to alter ORMSupportClasses\DependencyInjection\DependencyInjectionInfoProvider.cs and build your own version of the ORMSupportClasses dll.

I've found ans tried this

DependencyInjectionDiscoveryInformation.PerformAutoDiscoveryDependencyInjectionInformation = true;

But it doesn't work... it still doesn't do the job As the modification is tiny and without any effects on other code, is it possible to add this functionality in the next patch ? I only need it in 2 months...

Is this a windows or a web application?

Web service application (but I'm doing test with nunit) If I add

<add key="autoDependencyInjectionDiscovery" value="true"/>

in the config file, it works. So it really just a problem of telling the framework that he need to activate the DI. I just need a way of enable the DI in code, without modifying the config file.

The point is that this doesn't work as there's a catch22.

The DependencyInjectionInfoProvider is a singleton. The first time this type is in scope (so the first time you can set the flag you're proposing in code) the singleton instantiation ctor runs, which ... initializes the DI provider inner structures, by reading the config setting if it should do auto-discovery.

However, you want to set the flag to do auto-discovery, but that code will run after it does auto-discovery

The thing is that the way it is done now makes the store threadsafe, as it's not altered after it's created. This is crucial for a singleton.

This thus means that it can't be done what you propose, sorry.

Yes I had in mind the problem was something like this (config set too late).

I think it's quite simple to do, but I may be wrong : the only need is to separate the config from the DependencyInjectionInfoProvider . For example, there is allready a ConfigFileHelper. Simply add the property "PerformAutoDiscoveryDependencyInjectionInformation " in this class, which allow a set to override the config value. And the DependencyInjectionInfoProvider go read this property instead of his own property.

And then, it's up to the framework user (me!) to develop so that this property is set before any reference to the DependencyInjectionInfoProvider (that will throw the static ctor)

Fab wrote:

Yes I had in mind the problem was something like this (config set too late).

I think it's quite simple to do, but I may be wrong : the only need is to separate the config from the DependencyInjectionInfoProvider . For example, there is allready a ConfigFileHelper. Simply add the property "PerformAutoDiscoveryDependencyInjectionInformation " in this class, which allow a set to override the config value. And the DependencyInjectionInfoProvider go read this property instead of his own property.

And then, it's up to the framework user (me!) to develop so that this property is set before any reference to the DependencyInjectionInfoProvider (that will throw the static ctor)

That's not always safe. The CLR sometimes executes a static ctor if you load a type which refers to the static type, at least I've seen that happen sometimes. If it suspects a codepath will lead to it, it's already too late.

This makes it fragile to work with, as it's unpredictable what will happen.

Yes, but for example it allow to put it where I'm sure nothing have been loaded before ... like in the global.asax on Appplication_Startup.

But I've found another way to do it:

            if (ConfigurationManager.AppSettings["autoDependencyInjectionDiscovery"] == null)
            { // Add it to the configuration
                Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
                config.AppSettings.Settings.Add("autoDependencyInjectionDiscovery", "true");
                config.Save(ConfigurationSaveMode.Modified);
                ConfigurationManager.RefreshSection("appSettings");
            }

It dynamically update the config file if the setting isn't present.

Tx for your help

Just want to add some thoughts I think it's dangerous to put this config mandatory in the config file to allow the DI to works and not offer a way to config it in code. I don't want to make this point configurable, the DI must always be activated as it allow some very important module to work : Concurrency check & Validation. If the config is missing for some reason (intentional or not) we can have data loss... without seeing it as the application will run without errors.

This was for my particular case, but let me make some generalisation...

Take an Client/Server application with Auditors and Authorizer developped to put some security. Do you think it's normal to allow the final user to disable these functionalities just by modifying the application config ? And so he'll have all permissions with audit disabled ?

I just talk about that because I know in the future I'll use these functionalities...

Fab wrote:

Just want to add some thoughts I think it's dangerous to put this config mandatory in the config file to allow the DI to works and not offer a way to config it in code. I don't want to make this point configurable, the DI must always be activated as it allow some very important module to work : Concurrency check & Validation. If the config is missing for some reason (intentional or not) we can have data loss... without seeing it as the application will run without errors.

That's a side effect of having dependency injection based on a config file.

You can also use DependencyInjection scopes, which are local to a thread. To set these up, please consult the manual, and you can then do your DI configuration manually.

This was for my particular case, but let me make some generalisation...

Take an Client/Server application with Auditors and Authorizer developped to put some security. Do you think it's normal to allow the final user to disable these functionalities just by modifying the application config ? And so he'll have all permissions with audit disabled ?

I just talk about that because I know in the future I'll use these functionalities...

I understand what you're saying, but as I described above: there's no other way to do it. If you want to have code-driven DI, you can use dependency injection scopes.

besides that, if a user can alter the config file, you really think the app is then still 'secure'? The user can also run ildasm or reflector, change things and re-assemble it. Signed code doesn't help there, sn has a setting which disables signature checks.

I've put the above code (to change the config in runtime) in the static ctor of my adapter class .. the one that inherit from the generated class. And it works. So it's not so difficult to find a place where it's sure the DependencyInjection have not yet run. Of course, this is a fresh development, the future will tell me if it works in all cases . But I don't see any case that can load the DependencyInjection without first load my adapter class. I think your problem isn't really from making this modification, but instead it's in the support you'll have to bring to all those who can't use the property correctly (= enable too late)

Otis wrote:

besides that, if a user can alter the config file, you really think the app is then still 'secure'? The user can also run ildasm or reflector, change things and re-assemble it. Signed code doesn't help there, sn has a setting which disables signature checks.

In my example, the application is installed on a user machine .. so this user have access to the config file. It's quite basic to change a text file and see what happend. Even if the user is not a developper. Changing the IL isn't an easy stuff ... not so many people can do it (I can't... never tried or even look into the IL)... and impossible for basic user.

But this isn't blocking me as I found a work around, it's just "dommage" (in english ... "a pity" ?) that I need some ugly hack to make it works