New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
alexmg opened this Issue Nov 5, 2014 · 52 comments

Comments

Projects
None yet
10 participants
@alexmg
Contributor

alexmg commented Nov 5, 2014

This issue contains a list of (potential) tasks that need to be performed for Autofac 4.0 and adding support ASP.NET vNext.

  • Create a develop branch following Gitflow.
  • Make sure MyGet can build from the develop branch.
  • Update the Autofac project to Profile259 to make the PCL compatible with aspnetcore50 framework target.
  • Add .kproj files for Autofac and Autofac.AspNet.
  • Add sample application for ASP.NET vNext.
  • Remove NuGet dependencies on Autofac package while changes being made.
  • Split out non-core projects to separate repositories.
  • 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.
  • Tag the master branch with 3.5 prior to merging 4.0 into master (part of Gitflow anyway, but tags are required for doc site versions).
  • Tag the master branch with 4.0 after bringing the develop code in (also part of Gitflow, also required for doc site).
  • Update Autofac.Extensions.DependencyInjection to be strong named when the strong named version of Microsoft.Extensions.DependencyInjection is released.
  • Update to netstandard from dotnet TFM when released.
  • Add support for IGetRequiredServiceAware in Autofac.Extensions.DepedencyInjection
  • Add release notes to project.json/nuspec files to point to the wiki release note pages for each package. (Moved to #590)
  • Update the package icon URL in project.json/nuspec to point to the GitHub URL for the icon rather than Google Code.
  • Create a new version of the documentation site for 4.0.
  • Finalize the 4.0 behavior based on changes that are being looked at for ASP.NET Core integration.
  • Generate an updated version of the API documentation for 4.0.
  • Update the autofac.org web site for 4.0. (Moved to #823)
  • Finish porting the list of integration libraries
  • Update the Examples repository to the latest integrations.
  • Create an upgrade guide for 3.x to 4.0 for core Autofac and integration libraries. (Moved to autofac/Documentation#29)

@alexmg alexmg self-assigned this Nov 5, 2014

@alexmg alexmg added this to the v4.0 milestone Nov 5, 2014

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Nov 12, 2014

Contributor

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.

Contributor

tillig commented Nov 12, 2014

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Nov 20, 2014

Contributor

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
Contributor

tillig commented Nov 20, 2014

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
@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Nov 20, 2014

Contributor

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.

Contributor

tillig commented Nov 20, 2014

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jul 21, 2015

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.

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.

@alexmg

This comment has been minimized.

Show comment
Hide comment
@alexmg

alexmg Jul 26, 2015

Contributor

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

Contributor

alexmg commented Jul 26, 2015

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

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Sep 4, 2015

Contributor

Version 4.0.0-beta7-130 now targets dotnet.

Contributor

tillig commented Sep 4, 2015

Version 4.0.0-beta7-130 now targets dotnet.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Sep 9, 2015

Contributor

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.

Contributor

tillig commented Sep 9, 2015

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Sep 11, 2015

Contributor

For tracking integration library updates to Autofac 4...

  • Autofac.Configuration
  • Autofac.Extras.AggregateService
  • Autofac.Extras.AttributeMetadata - renamed from Autofac.Extras.Attributed
  • Autofac.Extras.CommonServiceLocator
  • Autofac.Extras.DomainServices
  • Autofac.Extras.DynamicProxy
  • Autofac.Extras.EnterpriseLibraryConfigurator
  • Autofac.Extras.FakeItEasy
  • Autofac.Extras.Moq
  • Autofac.Extras.MvvmCross
  • Autofac.Extras.NHibernate
  • Autofac.Mef
  • Autofac.Multitenant - renamed from Autofac.Extras.Multitenant
  • Autofac.Multitenant.Wcf - renamed from Autofac.Extras.Multitenant.Wcf
  • Autofac.Mvc
  • Autofac.Mvc.Owin
  • Autofac.Owin
  • Autofac.SignalR (Autofac.SignalR2)
  • Autofac.Wcf
  • Autofac.Web
  • Autofac.WebApi (Autofac.WebApi2)
  • Autofac.WebApi.Owin (Autofac.WebApi2.Owin)

(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.

Contributor

tillig commented Sep 11, 2015

For tracking integration library updates to Autofac 4...

  • Autofac.Configuration
  • Autofac.Extras.AggregateService
  • Autofac.Extras.AttributeMetadata - renamed from Autofac.Extras.Attributed
  • Autofac.Extras.CommonServiceLocator
  • Autofac.Extras.DomainServices
  • Autofac.Extras.DynamicProxy
  • Autofac.Extras.EnterpriseLibraryConfigurator
  • Autofac.Extras.FakeItEasy
  • Autofac.Extras.Moq
  • Autofac.Extras.MvvmCross
  • Autofac.Extras.NHibernate
  • Autofac.Mef
  • Autofac.Multitenant - renamed from Autofac.Extras.Multitenant
  • Autofac.Multitenant.Wcf - renamed from Autofac.Extras.Multitenant.Wcf
  • Autofac.Mvc
  • Autofac.Mvc.Owin
  • Autofac.Owin
  • Autofac.SignalR (Autofac.SignalR2)
  • Autofac.Wcf
  • Autofac.Web
  • Autofac.WebApi (Autofac.WebApi2)
  • Autofac.WebApi.Owin (Autofac.WebApi2.Owin)

(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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Sep 11, 2015

Contributor

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.
Contributor

tillig commented Sep 11, 2015

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.
@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Sep 11, 2015

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/

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/

@Sm1le291

This comment has been minimized.

Show comment
Hide comment
@Sm1le291

Sm1le291 Oct 14, 2015

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

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

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Oct 14, 2015

Contributor

@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.

Contributor

tillig commented Oct 14, 2015

@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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Oct 15, 2015

Contributor

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.

Contributor

tillig commented Oct 15, 2015

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Oct 15, 2015

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.

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.

@Sm1le291

This comment has been minimized.

Show comment
Hide comment

@tillig thanks=)

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Oct 15, 2015

Contributor

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.

Contributor

tillig commented Oct 15, 2015

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Oct 15, 2015

Contributor

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.

Contributor

tillig commented Oct 15, 2015

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Nov 3, 2015

Contributor

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.

Contributor

tillig commented Nov 3, 2015

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Nov 19, 2015

Contributor

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.

Contributor

tillig commented Nov 19, 2015

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.

@mikolesnikov

This comment has been minimized.

Show comment
Hide comment
@mikolesnikov

mikolesnikov Nov 19, 2015

"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.

"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.

@tcabanski

This comment has been minimized.

Show comment
Hide comment
@tcabanski

tcabanski Nov 28, 2015

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?

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?

@NPadrutt

This comment has been minimized.

Show comment
Hide comment
@NPadrutt

NPadrutt Dec 17, 2015

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

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

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Jan 7, 2016

Contributor

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.

Contributor

tillig commented Jan 7, 2016

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jan 7, 2016

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.

onovotny commented Jan 7, 2016

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.

@tillig tillig changed the title from Autofac 4.0 and ASP.NET vNext tasks to Autofac 4.0 and ASP.NET Core / .NET Core Tasks Apr 19, 2016

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Apr 19, 2016

Contributor

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.

Contributor

tillig commented Apr 19, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Apr 19, 2016

Contributor

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.

Contributor

tillig commented Apr 19, 2016

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Apr 19, 2016

@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?

@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?

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Apr 19, 2016

Contributor

@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.

Contributor

tillig commented Apr 19, 2016

@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.

@alexmg

This comment has been minimized.

Show comment
Hide comment
@alexmg

alexmg Apr 23, 2016

Contributor

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.

Contributor

alexmg commented Apr 23, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig May 7, 2016

Contributor

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.

Contributor

tillig commented May 7, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig May 11, 2016

Contributor

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.

Contributor

tillig commented May 11, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig May 12, 2016

Contributor

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).

Contributor

tillig commented May 12, 2016

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).

@zeroskyx

This comment has been minimized.

Show comment
Hide comment
@zeroskyx

zeroskyx May 18, 2016

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

zeroskyx commented May 18, 2016

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

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig May 31, 2016

Contributor

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.

Contributor

tillig commented May 31, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Jun 8, 2016

Contributor

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

Contributor

tillig commented Jun 8, 2016

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

@Serjster

This comment has been minimized.

Show comment
Hide comment
@Serjster

Serjster Jun 28, 2016

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

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

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Jun 28, 2016

Contributor

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.

Contributor

tillig commented Jun 28, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Jun 28, 2016

Contributor

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.

Contributor

tillig commented Jun 28, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Jun 30, 2016

Contributor

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.

Contributor

tillig commented Jun 30, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Jun 30, 2016

Contributor

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.

Contributor

tillig commented Jun 30, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Jun 30, 2016

Contributor

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.

Contributor

tillig commented Jun 30, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Jul 12, 2016

Contributor

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.

Contributor

tillig commented Jul 12, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Jul 21, 2016

Contributor

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.

Contributor

tillig commented Jul 21, 2016

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.

@Serjster

This comment has been minimized.

Show comment
Hide comment
@Serjster

Serjster Aug 1, 2016

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?

Serjster commented Aug 1, 2016

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?

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Aug 1, 2016

Contributor

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.

Contributor

tillig commented Aug 1, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Aug 10, 2016

Contributor

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.

Contributor

tillig commented Aug 10, 2016

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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Aug 17, 2016

Contributor

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.

Contributor

tillig commented Aug 17, 2016

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.

@OzBob

This comment has been minimized.

Show comment
Hide comment
@OzBob

OzBob Sep 9, 2016

@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

OzBob commented Sep 9, 2016

@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

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Sep 9, 2016

Contributor

@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.

Contributor

tillig commented Sep 9, 2016

@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.

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Oct 5, 2016

Contributor

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

Contributor

tillig commented Oct 5, 2016

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

@tillig

This comment has been minimized.

Show comment
Hide comment
@tillig

tillig Jan 3, 2017

Contributor

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.

Contributor

tillig commented Jan 3, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment