"Default" 3.0.2 download contains SL binaries

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Download Autofac 3.0.2 from 
https://code.google.com/p/autofac/downloads/detail?name=Autofac.3.0.2.zip&can=2&
q=
2. Open Autofac.dll in decompiler

What is the expected output? What do you see instead?
I would expect the "default" .NET binaries, instead it's a SL build of Autofac. 
Evident by the version of System.Core it depends on. I just upgrade from 
Autofac 2.6 and it depends on System.Core 4.0.0. The binaries I got for 3.0.2 
depend on System.Core 2.0.50, causing errors on some of my production machines 
which don't have Silverlight binaries in the GAC.

Only after debugging for a few hours I realized that the download page linked 
above actually says "portable", it's just that I never noticed and the zip name 
does not indicate it.

Please provide a sensible "default" zip with the standard binaries, and make 
specialised binaries explicit in the archive name (like done with other 
extensions already; I would expect something like "Autofac.3.0.2.Portable").

Please use labels and text to provide additional information.

Original issue reported on code.google.com by estrada.raphael on 4 Jul 2013 at 10:21

[GoogleCodeExporter]

Sorry the System.Core I quote above shouldn't have been "2.0.50" but "2.0.5.0"

Original comment by estrada.raphael on 4 Jul 2013 at 10:25

[GoogleCodeExporter]

To add to this, I got the latest 3.0.2 via public NuGet repo and both the 
"net40" and the "portable" binary folders within it contain SL assemblies. The 
"net40" really should have an assembly using System.Core 4.0.0

Original comment by estrada.raphael on 4 Jul 2013 at 10:33

[GoogleCodeExporter]

I'm struggling to find a clean NET40 build from any official source. Forcing me 
to install the Portable Class Library doesn't seem like a viable alternative :-/

Original comment by estrada.raphael on 4 Jul 2013 at 10:59

[GoogleCodeExporter]

OK, apparently the source code move to use the Portable Class Libraries in ver3 
totally broke on our prod machines; ironic given that in order to be portable 
you need to install it on machines that are running .NET 4 perfectly fine. It 
would be great if the binaries in the nuget package located under "net40" 
actually had net4 in them, though rather than SL.

I'm afraid I will have to revert back to 2.6 because of this. 3 is unusable for 
me now - unfortunate, because feature wise and all it is perfectly compatible. 

I tried building from source but the entire process in VS/MSBuild is totally 
hard-wired to be "portable", preventing me from building a proper net40 without 
wasting more time on this :-/

Original comment by estrada.raphael on 4 Jul 2013 at 11:46

[GoogleCodeExporter]

this is not a new issue, apparently others are seeing it to

example:
http://devlicio.us/blogs/derik_whittaker/archive/2012/07/23/fileloadexception-co
uld-not-load-file-for-version-2-0-5-0-portable-class-library.aspx

I don't think it was a good move to add yet another dependency to Autofac. 
Without installing things to my prod machines (not an option right now, prod 
critical and there are LOTS) I won't be able to use ver3

Original comment by estrada.raphael on 4 Jul 2013 at 11:50

[GoogleCodeExporter]

The weird version number is  not actually a problem and is how PCL works. The 
portable assembly works with .NET 4.0+, Windows Phone 8, Silverlight 5 and 
Windows Store apps.

Travis has a blog post about this:

http://www.paraesthesia.com/archive/2013/03/29/portable-class-library-answers.as
px

There is also a section in the FAQ on the wiki:

https://code.google.com/p/autofac/wiki/FrequentlyAskedQuestions

Original comment by alex.meyergleaves on 4 Jul 2013 at 12:59

• Changed state: Invalid

[GoogleCodeExporter]

I understand that. Point is though, you basically broke compatibility with .NET 
4 before a very new version in an effort to become portable.

Original comment by estrada.raphael on 4 Jul 2013 at 2:01

[GoogleCodeExporter]

So given that this is invalid now, I understand that you guys are officially 
dropping support for .NET 4 from before that patch? A very disappointing 
decision. You could at least build .NET 4 proper and include it in the releases.

Original comment by estrada.raphael on 4 Jul 2013 at 2:13

[GoogleCodeExporter]

That patch was published on the 6/8/2011 and the first 3.0 release wasn't until 
January 2013. I have not seen a machine without this patch or a newer version 
of the framework installed (Microsoft .NET Framework 4 Platform Update 1) for a 
very long time. We moved to PCL to support a wider range of runtimes without 
having multiple projects or directives littered throughout the code. Prior to 
this it was essentially impossible to test the surface area of Autofac against 
different runtimes because there aren't unit test runners for each them. Is 
there a reason you have not updated the .NET Framework on your machine?

Original comment by alex.meyergleaves on 4 Jul 2013 at 2:23

[GoogleCodeExporter]

I understand why you did it, I just don't understand why there's no simple way 
to get the source to build .NET 4 explicitly without the esoteric PCL magic. I 
just created a new solution with new projects and my own nuspec file using .NET 
4 and copy pasted all of the Core and Configuration files into that new 
solution so I can build a .NET 4 proper assembly... this is not going to scale 
well.

It's not just my random dev box, otherwise this would be easy. We have swarms 
of servers out there that are running all kinds of .NET apps just fine, but 
just seem to be missing this update for whatever reason (they are not connected 
to standard Windows Update for various reasons). These are business critical 
boxes for which there is procedure and whatnot, and it will be a difficult 
argument to roll out a patch just so I can use Autofac 3.

Original comment by estrada.raphael on 4 Jul 2013 at 2:43

[GoogleCodeExporter]

I got my hand-built Autofac3 working now. Works fine on the boxes in question. 
I guess I'll have to stick with this crutch for the foreseeable future.

I didn't mean to offend anyone here, I love Autofac and the work you guys put 
into it. But the irony that I can't use the newest version because it's now 
more portable is just killing me :-/

Original comment by estrada.raphael on 4 Jul 2013 at 2:57

[GoogleCodeExporter]

I'm glad you got it working, and can assure you no offence was taken. It's 
always frustrating hitting roadblocks when trying to move to something new (we 
hit plenty of those ourselves). Hopefully over time you can get those boxes 
up-to-date and won't have to worry about the custom build. Introducing 
something like the PCL was always going to involve some growing pains. Overall 
we are fairly happy with how it has worked out, and we are seeing a lot less of 
these kinds of issues. Autofac 2.6 was a solid release and if it continued to 
meet your requirements there is nothing wrong with sticking with something that 
works. :)

Original comment by alex.meyergleaves on 5 Jul 2013 at 12:51