I have put a new 4.5.492 prerelease online, leading up to the 4.5.500 release.
This prerelease supports WinRT 8.1 and the latest Xamarin Android versions, and includes a number of bug fixes and enhancements people have asked for over the past few weeks.
Please give this version a try ASAP and let me know if you encounter any issues. My plan is to do the final release in about a week barring any major issues you all might find.
We have installed 4.5.492 using nuget but cannot build any of our .net 4 applications with it. When starting a new project with .net 4.5 it builds fine but when I change the framework to .net 4 and install from nuget again the project can no longer build.
When the Target Framework is .net 4 we receive the following error:
"The type or namespace name 'Csla' could not be found (are you missing a using directive or an assembly reference?)"
Johnny mentioned in a separate thread: "CSLA 4.5 only supports .NET 4.5.".
Just a heads up.
Jonny did some work so it should be available on .NET 4 as well as 4.5. Perhaps something went wrong in the build/release scripts.
I did some work on the DataPortal Proxy for WCF in .NET 4 as it had been generated with .NET 4.5 and included Task type in proxy.
I am puzzeled as to what the problem i and I can easily recreate the issue with just create a .NET 4 project and and NuGet reference to CSLA.
Seems like we have a mismatch in the references to Microsoft.Bcl.Asyn in Csla.dll and the NuGet package definition. Which is quite strange as the dependency does NOT specify a specific version so it should be the latest version.
So open NuGet Package Manager and make sure to update to the latest Microsoft.Bcl.Async package and the project(s) will compile and run fine.
IE: On the first add NuGet reference the project gets the following references:
<packages> <package id="CSLA-Core" version="4.5.492-Beta" targetFramework="net40" /> <package id="Microsoft.Bcl" version="1.0.19" targetFramework="net40" /> <package id="Microsoft.Bcl.Async" version="1.0.165" targetFramework="net40" /> <package id="Microsoft.Bcl.Build" version="1.0.13" targetFramework="net40" /> </packages>
And after i update to the latest NuGet package for Microsoft.Bcl.Async i get
<packages> <package id="CSLA-Core" version="4.5.492-Beta" targetFramework="net40" /> <package id="Microsoft.Bcl" version="1.1.6" targetFramework="net40" /> <package id="Microsoft.Bcl.Async" version="1.0.165" targetFramework="net40" /> <package id="Microsoft.Bcl.Build" version="1.0.13" targetFramework="net40" /> </packages>
And NOW the project will compile fine.
So CSLA for NET4 only specifies a NuGet dependency to Microsoft.Bcl.Async which in turn has a dependency to Micorosft.Bcl (≥ 1.0.19) and we get an older reference assembly than what CSLA was compiled with.
@Rocky - we may "downgrade" Csla 4 to compile against the 1.0.19 package or specify a reference to the newer package Microsoft.Bcl.
Looks like NuGet is getting us into another kind of DLL HELL.
Thanks a lot that fixes the problem.
FWIW: In my opinion the Bcl team messed up on the NuGet package references on Microsoft.Bcl.Async package.
They should have specified a dependency to the Microsoft.Bcl >= 1.1.2 and NOT >= 1.0.19 as this means that NuGet will only try to find the latest package of the 1.0.* version (and does not resolve to the latest package of 1.1.* which is the 1.1.6 version released on the same date as Microsoft.Bcl.Async)
Jonny, do you think we can just explicitly require that package in CSLA's package to fix the issue?
Explicitly requiring the newer version of the bcl assembly seems to work, and the fix is now in the latest nuget prerelease.
When upgrading to 4.5.500 this exact same problem arises and there are no updates available to Microsoft.Bcl.
I confess nuget is one of those things I don't work with much and I just "hope it works".
In upgrading to CSLA 4.5.500, I'm getting a "Could not load file or assembly System.Threading.Tasks" for 22.214.171.124. The version that comes down when applying from nuget to our solution projects is 126.96.36.199.
I notice CSLA happens to have 188.8.131.52 for this dll.
I'm trying to figure out what the right answer is as I'm starting to scan through the threads - I notice one mentions compiling CSLA with the earlier version of Microsoft.Bcl...
EDIT: Going into package manager's updates "tab" I saw the update for Microsoft.Bcl to 1.1.6. Applied that and it looks like my CSLA upgrade is complete.
We currently have 4.5.40 working perfectly in our .net 4 projects, so it must be something specific to 4.5.492.
Is it possible to get Jonny's opinion on this or should we wait for the next release to see if the issue is resolved?
We'll be downloading the final release and putting it into some good testing (with our next product release) once it's available, fwiw. Keeping my eye out!
Copyright (c) Marimer LLC