Autofac 4.0 and ASP.NET Core / .NET Core Tasks

Question

Autofac 4.0 and ASP.NET Core / .NET Core Tasks

alexmg opened this issue 10 years ago · 52 comments

Answer 1 · 2014-11-12T19:43:18.000Z

There may be some challenge creating the new doc site version prior to splitting out repositories. The way Read the Docs Versioning works is it's looking for tags on the codeline.

While it seems to see the develop branch, I am unable to enable it as visible through the administrative interface. I set it as active, the setting gets ignored with no error message or info. I'm guessing it has to do with no tags being in place.

I'll add some tagging tasks to the list to see if that remedies the issue.

Answer 2 · 2014-11-20T16:45:42.000Z

Separate repos created for non-core projects. Changes we should announce when things are closer to working:

Deprecated: Autofac.Extras.NHibernate
Deprecated: Autofac.Extras.EnterpriseLibraryConfigurator
Deprecated: Autofac.Integration.DomainServices
Renamed: Autofac.Extras.Attributed => Autofac.Extras.AttributeMetadata
Renamed: Autofac.Extras.Multitenant => Autofac.Multitenant
Renamed: Autofac.Extras.Multitenant.Wcf => Autofac.Multitenant.Wcf
Renamed: Autofac.Extras.DynamicProxy2 => Autofac.Extras.DynamicProxy

Answer 3 · 2014-11-20T20:57:45.000Z

EF 7 was provided by Damian Edwards as a well-set-up repo that has some ASP.NET 5 code in it. I'm going to have to look in there to see how the automated build works. So far it doesn't appear straightforward, with the compiler and build system being dynamically downloaded via NuGet to bootstrap the process.

Answer 4 · 2015-07-21T15:27:55.000Z

One update here. You can read more on my blog, but the target here shouldn't be dnx451 or dnxcore*

Instead for Autofac, it should use dotnet. That is what CoreCLR things should target and will then support anything its contracts do. DNX isn't the only thing that can use it in other words.

I suspect that the Autofac main core package does not actually need any DNX-specific types/libraries, it needs CoreCLR. Then the other package (the former autofac.dnx one) does reference dnx-specifics and should target dnx*. Point being that the main autofac shouldn't as it'd work on more platforms than that.

Answer 5 · 2015-07-26T08:03:58.000Z

Thanks for the comment @onovotny and great blog post. I've created issue #668 to investigate switching to the dotnet target framework.

Answer 6 · 2015-09-04T15:56:06.000Z

Version 4.0.0-beta7-130 now targets dotnet.

Answer 7 · 2015-09-09T16:50:11.000Z

Started update of the Autofac.Multitenant repo including the rename of Autofac.Extras.Multitenant to Autofac.Multitenant. Next release of that package (4.0.0-beta8-*) will include that update.

Answer 8 · 2015-09-11T14:41:19.000Z

For tracking integration library updates to Autofac 4...

(Wow, there are a lot of these...)

Items marked "in beta" are things that need to be moved along with Autofac core due to the change in build from .csproj to DNX, due to a dependency being in beta, or some other reason. Items checked off are done and published to NuGet, set to be compatible with Autofac < 5.0.0.

Versions are updated to 4.0 since they require Autofac 4.0 and drop .NET 4.0 support.

I may go back and see if I can get the updated code working against the latest stable pre-4.0 Autofac for easier upgrade support, but dropping .NET 4.0 still means we should rev the major semver, I think.

Answer 9 · 2015-09-11T18:55:53.000Z

Two links I've found helpful in working through this:

DNX Roadmap - shows when the beta releases are targeted to ship. Looks like beta 8 is supposed to be feature-complete, so hopefully the churn slows down.
Demystifying PCL’s, .NET Core, DNX and UWP - blog from @onovotny with a table showing the compatibility of different framework targets. I've referred to this several times.

Answer 10 · 2015-09-11T18:57:52.000Z

Just a head's up that dotnet doesn't actually imply a specific TFM, unlike that blog article -- that was my understanding at the time.

These two are newer/more accurate:
http://oren.codes/2015/06/16/demystifying-pcls-net-core-dnx-and-uwp-redux/
http://oren.codes/2015/07/29/targeting-net-core/

Answer 11 · 2015-10-14T18:08:52.000Z

Hi! I have question about deleting IScopedInstance interface. This change affected you implementation?
If affected, works Autofac with Beta 7 of vNext ?

Answer 12 · 2015-10-14T18:19:31.000Z

@Sm1le291 Autofac.Extensions.DependencyInjection (used to be Autofac.Framework.DependencyInjection) is versioned along with the DNX version for which it's compatible. We're currently on 4.0.0-beta7, which is thus compatible with DNX beta 7. When beta 8 ships, we'll push a beta 8 compatible version. And so on, until DNX release.

Answer 13 · 2015-10-15T00:52:42.000Z

It appears that in order to solve #663 and provide some back-compat with older PCL formats and NuGet/VS versions, we still have to reference the old crazy portable-blah-blah-blah target framework monikers.

I tried creating an old-school PCL and can't add Autofac 4 as a dependency because it's not resolving dotnet as being compatible.

Answer 14 · 2015-10-15T01:10:24.000Z

Part of it depends on VS 2015 vs VS 2013 and also the PCL project types. If your PCL includes .NET 4 or SL, then it won't be compat with dotnet either :/

The safest thing to do is to include the portable- and whatever you add for the newer stuff. The trick is what's in the dotnet folder; if it's a PCL259, you're ok. Otherwise you may need to put the older PCL in platform folders so that a newer dll doesn't get provided to an older platform. Basically, the way it's currently implemented, dotnet resolves to anything .net 4.5+ and store/wp, xamarin, etc.

Answer 15 · 2015-10-15T06:34:31.000Z

@tillig thanks=)

Answer 16 · 2015-10-15T14:51:53.000Z

Putting back the .NETPortable,Version=v4.5,Profile=Profile259 target in core Autofac seems to fix the issues with compatibility with PCL in VS 2013 and non-project.json PCL in VS 2015. The appropriate portable-net45+dnxcore50+win+wpa81+wp80+MonoAndroid10+Xamarin.iOS10+MonoTouch10 package folder gets created with the correct contents to make that work.

Answer 17 · 2015-10-15T21:26:27.000Z

We may need to add some tests around disposal and not double-disposing for the DependencyInjection adapter. It appears some recent changes in the way disposables are tracked caused the StructureMap adapter to start failing tests.

Answer 18 · 2015-11-03T16:32:28.000Z

I just updated Autofac on the develop branch to use the new dotnet5.2 TFM but it seems to be pretty early. I've worked out a lot of the kinks, but I'm not able to add a reference to it from a classic PCL so it regresses issue #663.

I'm hoping the dotnet5.2 TFM will work because I think it'll fix the build issue I'm having in trying to get Autofac.Configuration to be compatible with the same platforms as Autofac core.

Answer 19 · 2015-11-19T16:13:43.000Z

Published Autofac and Autofac.Extensions.DependencyInjection 4.0.0-rc1-177 to NuGet with ASP.NET 5 RC1 compatibility. Once again, weird things in the rc1 release. The non-ASP.NET dependencies have skipped from -beta-* to -rc2-* and all of the ASP.NET dependencies are still on -beta-* so that's not in line anymore. Also, the Microsoft.AspNet.Server.IIS dependency used by the sample project is still on beta7 because they've never released anything later than that to NuGet.

I'll see if I can get Autofac.Configuration up and running on rc1, too, but I'm not sure I can get to all the others immediately.

Answer 20 · 2015-11-19T21:58:31.000Z

"Microsoft.AspNet.Server.IIS" seems has been changed to "Microsoft.AspNet.IISPlatformHandler" which currently on 1.0.0-rc1-final.

https://www.nuget.org/packages/Microsoft.AspNet.IISPlatformHandler/1.0.0-rc1-final

I was able to get version 4.0.0-rc1-177 running on rc1. Looks like it's working.

Answer 21 · 2015-11-28T18:49:16.000Z

I can't get anything from Nuget to work with the latest ASP.NET 5 RC. However, I was able to build from this repo and get a local version working. What is the plan for getting this up on Nuget? Is there anywhere I can help?

Answer 22 · 2015-12-17T18:57:48.000Z

Same for PCL's with Profile 7 (used with xamarin on ios, android and windows 10).

Answer 23 · 2016-01-07T20:18:41.000Z

Status update: still trying to figure out NuGet package / compatibility issues. I think there's an odd gap going on between what NuGet supports, what VS supports, how dnu packages things, and the whole standard platform TFM change thing that's going on.

Per the remaining work tracking issue they've posted, as of today (1/7/2016) it appears NuGet still hasn't mapped all the PCL profiles which explains why Autofac, targeting dotnet5.2, isn't working on Profile7 stuff. I'm guessing that's also why support for UAP projects is jacked up.

It sounds like Autofac will have to switch from dotnet to netstandard before this mess is all over.

Finally, note that the stuff we release to NuGet is only going to work with the stuff the .NET folks have also released to NuGet - which is to say, if the .NET team has "officially released RC1" and that's what's on NuGet, that's what Autofac will also work with. If you're on RC2 (not released to NuGet) and Autofac from NuGet isn't working, try the Autofac MyGet feed... but note that we may stil be working on stuff like this in RC1 and may not have updated everything to RC2 (or whatever) quite yet. Thanks for your patience as we get to muddle through the craziness that ensues. 😄

Anyone interested in contributing, pull requests to the develop branch are accepted! It's pretty tricky to get this stuff working both on a local dev box and a build box, though, so watch the build indicator on the PR. Also, you may need to clear your entire DNX package cache to ensure you're building using the right set of package sources and not some custom/pre-pre-pre-release package you'e downloaded and cached in the past. (That gets me every time.)

@alexmg and I both had some time off during the end November / December time so there wasn't much traction. Sorry about that. Hopefully we can pick the momentum back up with the new year.

Answer 24 · 2016-01-07T21:38:10.000Z

This might be relevant:
http://www.twitter.com/DamianEdwards/status/685183642906173441

FWIW, the VS tools don't really support dotnet* either right now, at least not well. Hopefully this should all be sorted out by ASPNet 5 RC2/VS 2015 Update 2, however they ship it.

Answer 25 · 2016-04-19T16:19:03.000Z

Status update: We're still fighting through RC2 changes on the develop branch. We have the branch mostly building using the dotnet CLI but tests aren't running. It's been a big challenge and I'm not sure if the problem is with the set of dependencies we're taking, the framework monikers we're using, bugs / incomplete features in the dotnet CLI, something we're doing wrong... or some odd combination of all of these things.

It's a slow and painful process. Tips, hints, pull requests welcome to help us overcome this one.

Answer 26 · 2016-04-19T16:20:56.000Z

Note to folks looking for early RC2 drops: Once we actually have it building, you'll find the RC2 stuff on the MyGet feed. We'll push to NuGet when Microsoft pushes RC2 to NuGet.

Answer 27 · 2016-04-19T17:11:59.000Z

@NickCraver and I worked through getting Dapper building and tested with RC2:
https://github.com/StackExchange/dapper-dot-net/tree/netstandard/Dapper.Tests

I also have Humanizer building/testing with RC2 as well:
https://github.com/Humanizr/Humanizer/tree/dev/src/Humanizer.Tests.DotNet

Anything we can do to help?

Answer 28 · 2016-04-19T18:38:22.000Z

@onovotny A second (third?) set of eyes on the project.json files to make sure we're targeting the right things and have the right dependencies specified would help. I think they're right, but it'd be nice to verify. Autofac.Extensions.DependencyInjection tests are running but core Autofac tests aren't. Any ideas there would also help.

Answer 29 · 2016-04-23T08:21:37.000Z

I got the unit tests working now. The issue was in the build script and not the project.json.

MyGet now has 4.0.0-rc2-218 packages available.

Answer 30 · 2016-05-07T01:55:10.000Z

Looks like a couple weeks until RC2 settles out.

Thinking once we get an RC2 build of core Autofac out it'll be a full steam ahead effort to get updates for the other libs out as well as nail down final changes we might have for 4.0.

Answer 31 · 2016-05-11T22:04:03.000Z

I got the Roslyn code analyzers (e.g. FxCop, StyleCop) back into the build and properly running including a ruleset defining the set of rules not to run. Fixed up issues that have cropped up since we last had analysis in place, all minor stuff. This will be good to get into the Configuration build, too.

I pegged the dependencies to RC2 versions since the pre-release feeds we're using have RC3 stuff in them and I wanted to make sure we're binding against the right things that will be released.

Unit tests in Autofac.Test still don't run for me. Autofac.Extensions.DependencyInjection.Test tests do run.

Also seeing a lot of package restore messages like:

error: System.Collections 4.0.11-rc2-24103 provides a compile-time reference assembly for System.Collections on .NETStandard,Version=v1.1, but there is no run-time assembly compatible with win7-x64.

Answer 32 · 2016-05-12T17:13:23.000Z

It appears the unit test problem I ran into is a long-standing issue involving ongoing TFM work, something about netstandard vs netcoreapp vs net451 targeting. Search for dotnet-test Error: 0 : Microsoft.DotNet.Cli.Utils.CommandUnknownException: No executable found matching command and you'll see several issues, both open and closed.

Removing the net451 targets from the test projects gets the tests running and passing. Since we're not switching runtimes and executing the tests in different contexts anymore it seems an OK fix, at least until we put the runtime switching back in place (should we want that).

Answer 33 · 2016-05-18T19:58:30.000Z

Greetings,

RC2 bits are out on NuGet: http://www.nuget.org/packages/System.Runtime/4.1.0-rc2-24027
Both CLI and VS tooling can be found here: https://www.microsoft.com/net/core#windows

Best regards
-Simon

Answer 34 · 2016-05-31T16:46:39.000Z

I was going to do some additional updating on the develop branch for the build (and then propagate the changes to Autofac.Configuration so we can get two builds up and running) but the latest dotnet CLI preview build is broken and I'm now seeing this issue when trying to run unit tests:

xUnit.net .NET CLI test runner (64-bit .NET Core win81-x64)
System.TypeLoadException: Could not load type 'System.Runtime.InteropServices.GCHandle' from assembly 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

I tried pegging the dotnet CLI to a "known good" version and while that got me past some challenges, I haven't figured out this latest.

Answer 35 · 2016-06-08T01:33:16.000Z

I think we should figure out #755 (order of aspnet enumerables) prior to release - changing that after RTM would be breaking.

Answer 36 · 2016-06-28T14:59:25.000Z

Any clue on when Autofac will be ready for .NET Core RTM?

Answer 37 · 2016-06-28T15:09:55.000Z

Working on it. They introduced a few breaking changes between RC2 and RTM and we're still fighting #755, which is amazingly non-trivial for us. We'll probably issue an "RC3" version soon just for compatibility with the libraries and have to take a little extra time on #755 for full compatibility.

Answer 38 · 2016-06-28T17:30:43.000Z

I pushed an RTM-compatible version 4.0.0-rc3-280 to NuGet, though the ASP.NET DI integration still suffers from #755. This should at least unblock folks trying to upgrade their dependencies to RTM versions, though I anticipate there may be some breaking changes to get #755 out of the way so we're still non-RTM for Autofac.

Answer 39 · 2016-06-30T18:52:08.000Z

I'm working through the extras/integration libraries to ensure they can work with Autofac 4. For the most part, the changes are only that we switched to use the new .NET 4.5 security model (no more [AllowPartiallyTrustedCallers]) and verifying that a binding redirect from Autofac 3.x to Autofac 4.x beta still allows the unit tests to run. The list above gets updated as I get through things.

Answer 40 · 2016-06-30T19:24:03.000Z

It appears Castle.Core is working on supporting .NET Core which would mean we could update a lot of things (Autofac.Extras.DynamicProxy, Autofac.Extras.AggregateService) to support a wider platform spec, too, if we take that. I don't know what their timeline is, though, so it may be that we have a 4.0 release of those (AggregateService is already published) and then take the updated platform support as 5.0 for each.

Answer 41 · 2016-06-30T20:55:05.000Z

In order to get the DynamicProxy working against either Autofac 3.3.1 or Autofac 4.0 I had to change one test involving verifying that dynamic proxy mixins work. We had been using IDictionary<K,V> as the mixin interface but there was some weird parameter mismatch problem when using that after upgrading to Autofac 4.0.0. I couldn't track it down. However, I created a simpler interface without a tie to the .NET framework following this example and mixins do actually work. It seems to be a problem with specifically using IDictionary<K,V>. If it turns out that's something we need to support, we can open an issue. I have a feeling that will all change again once we update to support netstandard anyway.

Answer 42 · 2016-06-30T23:52:20.000Z

Looks like there's possibly some challenges getting the ASP.NET Core integration to work with multitenant support. I'll check into it.

Answer 43 · 2016-07-12T17:49:23.000Z

I fixed the multitenant issue by changing the way you create the initial AutofacServiceProvider.

Instead of
return container.Resolve<IServiceProvider>()
you now need to
return new AutofacServiceProvider(container)

The challenge was that multitenancy hooks in at the container level and everything you resolve from the container is already scoped to a tenant. By returning a resolved IServiceProvider we identify the tenant once and then every service is always scoped to that tenant forever after. Switching to the constructor-based syntax avoids that initial tenant identification and enables multitenancy to work again.

Answer 44 · 2016-07-21T23:43:03.000Z

I need to revisit some of the previously issued betas (e.g., Autofac.WebApi2, Autofac.WebApi2.Owin) to ensure they're working right with the .NET Core RTM and the current Autofac 4 RC out there. I know there are a couple of issues in there I'd like to nail before release, plus it looks like the .nuspec has the old Google Code image URL so some minor updates are still in order. Still working my way down the list in order, though, so those will probably be after I get the MVC stuff nailed down.

There are also some web site changes we want to make for the 4.0 release. Working on those after I get the betas for these integration packages out.

And we should probably generate updated API docs. That's not so straightforward with the dotnet CLI stuff. I'll add a checklist item to the top.

Answer 45 · 2016-08-01T19:28:42.000Z

Hey @tillig, just noticed that you're also heavily involved with Swagger/Swashbuckle, and like I asked there, is there a estimated date for Autofac 4 to come out of beta and into RTM?

Answer 46 · 2016-08-01T19:32:18.000Z

No, there is no estimated date. We're working as hard and fast as we can, but given this isn't a paid "day job," all I can say is "we'll get there as fast as possible." I'm not willing to commit to a date because it wouldn't mean anything.

Answer 47 · 2016-08-10T15:30:55.000Z

Autofac 4 core is released. Many of the integration libraries have also been updated for Autofac 4 compatibility (see the checklist above).

We'll keep working through the final changes as noted in the top checklist and the list of integration libraries until we've got it all out the door.

Answer 48 · 2016-08-17T16:28:03.000Z

I just pushed out the last of the integration libraries on the list for 4.0 compatibility. I also tagged the documentation at 4.0.0.

The examples aren't updated to the latest Autofac. I have a feeling that will be interesting since we dropped Silverlight support and one of the examples is a Silverlight example. Might be good to rethink the structure of them such that they aren't all "integrated" as a single solution and instead are more standalone examples, maybe with unit test drivers.

I haven't figured out a great way to generate API documentation (e.g., Sandcastle) across all the libraries. I'll keep working on it.

Answer 49 · 2016-09-09T01:49:59.000Z

@alexmg 's first post is a great overview of what MIGHT have been in Release 4.x.

I'm trying to assess the impact of upgrading to 4.1 ... and avoid making "it broke now what?" posts like: http://stackoverflow.com/questions/39364698/autofac-upgrade-to-version-4-0-0-is-missing-configurationsettingsreader (good one @tillig )

Where can I find documentation/information about upgrading from 3.5?
e.g. what's going to break and how to fix it ...

If not, where would you like me to document my findings, if any ...?

Addendum: For anyone else, there is a blog post on this subject: http://alexmg.com/autofac-4-0-0-is-in-the-wild/ from @alexmg

Answer 50 · 2016-09-09T02:01:30.000Z

@OzBob There really isn't an "upgrade guide." I'm not sure how that would be presented given the 20+ various integration libraries which may or may not require changes to adopt. I suppose we could add a new page for core Autofac in the documentation and then additional sections per integration library. As it stands, we're still settling all that out - you'll notice the examples repo isn't updated to the latest and we have some other "dot the 'i's, cross the 't's" detail tasks that haven't been completed.

If you have some feedback on what might go in (like what your experience is, gotchas you find) then leaving a note on this issue is as good a place as any to let us know.

In the meantime, I'll add a task item up top to create such a guide.

Answer 51 · 2016-10-05T23:34:25.000Z

Examples have been updated to include changes in interfaces as well as using the latest Autofac.

Answer 52 · 2017-01-03T19:40:42.000Z

Given there are three tasks remaining on the checklist for this huge issue, rather than just keep it open forever I'm going to create three smaller issues to track those three stragglers and close this one.