CSLA 4 version 4.5.492 prerelease online

CSLA 4 version 4.5.492 prerelease online

Old forum URL: forums.lhotka.net/forums/t/12243.aspx


RockfordLhotka posted on Monday, December 02, 2013

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.

clodewyks replied on Tuesday, December 10, 2013

Hi Rocky,

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?)"

Thanks

skagen00 replied on Tuesday, December 10, 2013

@clodewyks -

Johnny mentioned in a separate thread: "CSLA 4.5 only supports .NET 4.5.".

Just a heads up.

RockfordLhotka replied on Tuesday, December 10, 2013

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. 

JonnyBee replied on Wednesday, December 11, 2013

Hi,

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.

clodewyks replied on Wednesday, December 11, 2013

Hi Jonny,

Thanks a lot that fixes the problem.

JonnyBee replied on Thursday, December 12, 2013

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)

RockfordLhotka replied on Thursday, December 12, 2013

Jonny, do you think we can just explicitly require that package in CSLA's package to fix the issue?

RockfordLhotka replied on Wednesday, December 18, 2013

Explicitly requiring the newer version of the bcl assembly seems to work, and the fix is now in the latest nuget prerelease.

clodewyks replied on Wednesday, January 08, 2014

Hi Jonny,

 

When upgrading to 4.5.500 this exact same problem arises and there are no updates available to Microsoft.Bcl.

 

Any ieads?

skagen00 replied on Friday, January 10, 2014

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 2.6.6.0.  The version that comes down when applying from nuget to our solution projects is 2.5.19.0.

I notice CSLA happens to have 2.6.6.0 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.

clodewyks replied on Wednesday, December 11, 2013

@skagen00 -

We currently have 4.5.40 working perfectly in our .net 4 projects, so it must be something specific to 4.5.492.

 

Rocky,

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?

skagen00 replied on Tuesday, December 10, 2013

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