Autofac 4.0 and ASP.NET Core / .NET Core Tasks #594
Comments
|
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 I'll add some tagging tasks to the list to see if that remedies the issue. |
|
Separate repos created for non-core projects. Changes we should announce when things are closer to working:
|
|
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. |
|
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 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. |
|
Version 4.0.0-beta7-130 now targets |
|
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. |
|
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. |
|
Two links I've found helpful in working through this:
|
|
Just a head's up that These two are newer/more accurate: |
|
Hi! I have question about deleting IScopedInstance interface. This change affected you implementation? |
|
@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. |
|
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
I tried creating an old-school PCL and can't add Autofac 4 as a dependency because it's not resolving |
|
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. |
|
@tillig thanks=) |
|
Putting back the |
|
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. |
|
I just updated Autofac on the I'm hoping the |
|
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 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. |
|
"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. |
|
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? |
|
Same for PCL's with Profile 7 (used with xamarin on ios, android and windows 10). |
|
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 It sounds like Autofac will have to switch from 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 @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. |
|
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. |
|
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:
|
|
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 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). |
|
Greetings, RC2 bits are out on NuGet: http://www.nuget.org/packages/System.Runtime/4.1.0-rc2-24027 Best regards |
|
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: 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. |
|
I think we should figure out #755 (order of aspnet enumerables) prior to release - changing that after RTM would be breaking. |
|
Any clue on when Autofac will be ready for .NET Core RTM? |
|
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. |
|
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 |
|
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. |
|
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 |
|
Looks like there's possibly some challenges getting the ASP.NET Core integration to work with multitenant support. I'll check into it. |
|
I fixed the multitenant issue by changing the way you create the initial Instead of 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 |
|
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. |
|
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? |
|
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. |
|
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. |
|
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. |
|
@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? 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 |
|
@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. |
|
Examples have been updated to include changes in interfaces as well as using the latest Autofac. |
|
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. |
This issue contains a list of (potential) tasks that need to be performed for Autofac 4.0 and adding support ASP.NET vNext.
Use MSBuild target with .nuspec in each project to create NuGet packages.Package build is now done as part of AppVeyor build.Fix the assembly, file and package version numbers.Versioning is now controlled through appveyor.yml file.IGetRequiredServiceAwarein Autofac.Extensions.DepedencyInjectionThe text was updated successfully, but these errors were encountered: