Hoping someone could offer some insight as I've been battling with this for some time.
I have a long term CSLA (4.5.6) web project that I'm trying to add the latest version of Application Insights. This was a simple process however it did not work. The site worked as usualt but nothing was posted to Application Insights, i.e there was an error in the HTTP Module added by AI, with no source I couldn't track this down.
After a long process of trial and error I narrowed it down to some binding redirect in the config file..
<dependentAssembly> <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-2.5.19.0" newVersion="2.5.19.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-2.5.19.0" newVersion="2.5.19.0" /> </dependentAssembly>
Commenting this out resulted in Application Insights working however the site crashed completely. It seems Ai has a dependancy on the Microsoft.Bcl libraries (which incidently I didn't think were needed for 4.5) and adds the Microsoft.Threading.Tasks.*.dll's which kills CSLA.
Looking at CSLA source these are also referenced but never copied to bin folders.
Can anyone advise on the compatibility of the older .Net 4.0 async libs (ie Microsoft.Blc etc) and the CSLA. If I remove those dll;'s the app works again but Application Insights doesn't.
I don't think this is a CSLA issue but it would be nice to know what's going on. :(
Csla 4.5.600 used under .Net 4 also has dependencies on those same assemblies, but different versions. I think it needs 2.6.8 for System.Runtime and System.Threading.Tasks. Sounds like a version conflict and perhaps there are breaking changes in those assemblies.
You might be able to make everything happy by setting the newVersion to the 2.6.8.0 version Csla requires.
Where are you getting the version numbers from?
this is a project running under 4.5.
Those are from the assemblies needed to use async await in .net 4.0 via the bcl nugget packages. I would be surprised if they were smaller in .net 4.5 so if AI is installing older versions that would be an issue. did somehow the .net 4 version of AI get pulled in? Are you sure it works under 4.5?
Then you should recheck your references,
Csla 4.5.601 has
So make sure all you projects have target framework .NET 4.5.x and maybe remove and add the NuGet packages again.
Seems like your project i referencing the assemblies in the net40 folder in the nuget packages.
You can verify this by looking at properties on the references in your projects.
And for some reason the ApplicationInsights team has only provided assemblies for .NET 4.0 in the Microsoft.ApplicationInsights NuGet package.
So this package has dependencies to:
In my opinion the Microsoft.Bcl team broke the distribution chain when the made Microsoft.Bcl 1.0.x and 1.1.x and NuGet will initially always try to resolve/add the "lowest" compatible version number. So it is quite possible that you have references to 2 different versions of Microsoft.Bcl in your solution.
First: make sure that you have the correct references to CSLA 4.5 assemblies.
Test if all works fine!
Second: If still failure the open "Nuget Package Manager" on the solution and upgrade all packages.
I have checked all nuget packages...
CSLA is 4.5 version of 4.5.6 (confirmed using Dot Peek)
All other packages are up to date.
And without Application Insights there are no unexpected dependencies added to the projects. and everything works fine.
After adding Application Insights nuget package this add the BCL libraries/nuget packages. There are 3 main dll's to application insights two are 4.5 and one is 4. The application is dead after the first request. No errors just unresponsive. I don't think this is directly related to CSLA. Some other conflict that seem impossible to find.
First, I'm not aware of a release version of Csla which is 4.5.6. Do you mean 4.5.600 or 4.5.601?
Second, the BCL libraries shouldn't be needed as those became part of the .Net 4.5 framework; or rather, the BCL packages are only needed in .Net 4 as they backport the async / await features so that VS2012 users on .Net 4 can use them. But those same assemblies are already in the framework in 4.5, so you should no have any references to them.
It sounds like the AI package is not built correctly as it shouldn't be adding those BCL dependences since as I said they are already in .Net 4.5. Can you remove the reference to the 4.0 AI assembly as well as the binding redirects? Its possible that the 4.0 assembly should only get added if you're using .Net 4. I"ve seen a few packages that are built for both 4.0 and 4.5 but the 4.0 needs to "backport" some stuff not required in 4.5, much like the BCL is a backport of something which is just part of .net 4.5.
Yes I did mean 4.5.600......
Microsoft.ApplicationInsights.dll is built to .net 4.0 and has a dependency on the Bcl stuff. So it adds them. I have tried updating these libraries, this didn't work. I have removed them which fixed my app but then AI didn't work.
The strange/annoying thing is all the other Microsoft.ApplicationInsights.*.dll have been built to 4.5 except the root. one.
It is a pre-release so I'm hoping it's updated to 4.5 soon.
Have you tried removing the bcl references and updating the binding redirects to force use of the versions that come with the 4.5 framework?
Yes, same problem. :(
Microsoft.ApplicationInsights NuGet package does not include a .NET 4.5 binary in addition to the .NET 4.0 binary because that would force creation of additional binaries in NuGet packages that depend on it. The .NET 4 version of the Microsoft.ApplicationInsights.dll has a dependency on the Microsoft.Bcl and Microsoft.Bcl.Async nuget packages. Unlike Microsoft.Bcl package, Microsoft.Bcl.Async contains executable assemblies that are required by applications running on .NET 4.5. In other words, a .NET 4.5 application referencing Microsoft.ApplicationInsights.dll (a .NET 4.0 binary) should work. We have multiple web applications and services running successfully.
Can you help to narrow this problem down? Can you share a (preferably small) project we could use to reproduce the problem?
Copyright (c) Marimer LLC