kanayabhattad / autofac

Automatically exported from code.google.com/p/autofac
Other
0 stars 0 forks source link

Addition of optional parameter to ContainerBuilder.Update breaks projects that assume only one parameter #462

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Create a console project containing Atlas and Autofac 3.1.1, installed from 
NuGet
2. Add valid code to make the project work, e.g., in the Main method:

            var configuration =
                Host.UseAppConfig<MyServiceClassImplementingIAmAHostedProcess>()
                    .AllowMultipleInstances()
                    .WithRegistrations(b => b.RegisterModule(new MyAutoFacModule()))
                    .WithArguments(args);

            Host.Start(configuration);

3. Update the project to use Autofac 3.1.3
4. Run the project at the console using the "/c" argument.

What is the expected output? What do you see instead?

The project should start and execute the start method of 
MyServiceClassImplementingIAmAHostedProcess.
Instead it throws the following error:

Unhandled Exception: System.MissingMethodException: Method not found: 'Void 
Autofac.ContainerBuilder.Update(Autofac
.IContainer)'.

What version of Autofac are you using? 
Autofac 3.1.3.

Original issue reported on code.google.com by joshua.p...@googlemail.com on 23 Oct 2013 at 2:30

GoogleCodeExporter commented 8 years ago
The Atlas project isn't actually connected directly with Autofac so you might 
need to pursue this with them.

Have you tried adding a binding redirect to your app.config?
http://msdn.microsoft.com/en-us/library/eftw1fys.aspx

Original comment by travis.illig on 23 Oct 2013 at 11:41

GoogleCodeExporter commented 8 years ago
I was deliberately mentioning Atlas as a concrete example of the problem, but 
the real issue here is that there is a breaking change to the API in a minor 
version of the code. Adding a method parameter to an existing public method 
(without leaving the original signature as an overload) is a breaking change. 
Semantic versioning says that this ought to be a major version increase. 
Anything with a dependency on >= 3 and <4 should expect not to need to 
recompile between version 3.1.1 and 3.1.3, which is what is now required of (at 
least) Atlas.

Original comment by joshua.p...@googlemail.com on 31 Oct 2013 at 9:13

GoogleCodeExporter commented 8 years ago
The public parameter that was added is an optional parameter, so technically 
calling the original version of the method still works, assuming there's no 
reflection going on. (I think it's probably a gray area on whether API changes 
are "breaking" if the access is through reflection vs. direct call. I've not 
seen any discussion on it.) I have several projects I was able to update with 
no recompile.

Given that, it's a minor change that is technically backwards-compatible, and 
it was introduced as a bug fix for an incorrect Update method behavior, so the 
0.0.1 minor version was warranted.

Either way, it's solvable. We could add a single-parameter overload back in to 
fix the issue here easily enough and switch the optional parameter in the 
two-parameter overload to be required.

Original comment by travis.illig on 31 Oct 2013 at 11:48

GoogleCodeExporter commented 8 years ago

Original comment by travis.illig on 11 Nov 2013 at 9:35

GoogleCodeExporter commented 8 years ago
This issue was closed by revision 8ee9cd2f2f40.

Original comment by travis.illig on 6 Dec 2013 at 12:43

GoogleCodeExporter commented 8 years ago

Original comment by travis.illig on 6 Dec 2013 at 12:43