Rockford Lhotka's Blog

Home | Lhotka.net | CSLA .NET

 Sunday, October 28, 2012

I am of the opinion that classmates.com is a criminal organization.

In 2008 my wife decided to give them a try with their paid service. Every year since then she has tried to cancel the paid service. Every year they renew it anyway, and continue to increase the price each time.

This year we tried disputing the credit card charge. They sent the credit card company (Discover) a bunch of screen shots of the ancient transaction from 2008, but none of the subsequent requests for cancelation. I strongly suspect they’ve “lost” all our requests to cancel their service (which we never found remotely useful in the first place).

Discover sided with classmates.com and insists that the transaction is legal.

As a merchant, I find that the credit card companies never side with me. <scarcasm>Apparently I need to create better screen shots to send in the case of disputes, because that seems to be the trick to screwing over your customers.</sarcasm>

At this point I think we’ll end up canceling the credit card completely. Not only because Discover is assisting what seems like criminal theft of our money, but also because 12 months from now when classmates.com tries to steal some more money, they won’t be able to complete the transaction against a long-canceled credit card.

What recourse do I have as an individual in this case? In terms of raw cost, it’ll take thousands of dollars to sue classmates.com to get my $40/year from them, so it makes more financial sense to allow their continued theft of my money. Certainly there’s no way to get back the latest $40 theft…

Sunday, October 28, 2012 3:08:31 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [9]  | 
 Friday, October 26, 2012

At the .NET Rocks Road Trip event in Charlotte, NC this week an attendee asked if there’d be a way to run the new Windows Store apps on Windows 7.

These are apps running on the new Windows Runtime (WinRT) platform.

Basically the question was whether Microsoft would issue an update so WinRT apps can run on Windows 7.

My answer, which got a great laugh, but is actually serious, is that Windows 8 is the update to Windows 7 that allows it to run WinRT apps.

I acknowledge that this answer is loaded with humor. But I am also serious in my answer.

I’ve been running Windows 8 full time for a few months now, and haven’t run into any issues with Windows 7 apps not working on Windows 8 (except for a couple odd-ball Steam games that I suspect break some Win32 programming rules). All my work software, all my business software, and my important games (Battlefield 3, XCOM, Supreme Commander, L4D2) all work fine on Windows 8.

Windows 8 turns out to be a slightly faster version of Windows 7, that can also run WinRT apps. Hence, Windows 8 is the upgrade to Windows 7 that allows you to run Windows Store apps.

Friday, October 26, 2012 4:09:22 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Wednesday, October 24, 2012

I am pleased to announce the final release of CSLA 4 version 4.5 with support for the following platforms:

  • .NET 4.5
  • Windows Runtime (WinRT)
  • .NET 4
  • Silverlight 5

The new release is available via nuget and the CSLA download page.

This release includes a number of important features and changes, including:

  • Support for Windows Runtime (WinRT), so you can simply recompile your existing CSLA .NET business classes for WinRT with little or no changes required to migrate to the new platform
  • Support for the new async and await keywords in .NET 4.5 (and in .NET 4 and SL5 via the async targeting pack)
  • Enhancements to the business rules engine
  • Enhancements to Windows Forms support via the Csla.Windows namespace

The entire CSLA .NET dev team has put a lot of work into this release, and we hope you enjoy it and find it useful!

Wednesday, October 24, 2012 4:00:51 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Wednesday, October 17, 2012

CSLA 4 version 4.5 release candidate 1 is now online via installer and nuget.

This is a relatively minor update from the previous beta, with a small number of bug fixes. The big thing is that Tiago and Jonny put a lot of work into making sure the samples are all working with CSLA .NET 4.5.

My plan is to release version 4.5 by the middle of next week.

Wednesday, October 17, 2012 4:53:46 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Tuesday, October 09, 2012

CSLA 4 version 4.5 supports the async and await keywords across all platforms (WinRT, .NET 4.5, .NET 4, Silverlight 5).

You can use these async features to implement async rules in the CSLA rules engine. Here’s one such rule:

public class CustomRule : Csla.Rules.BusinessRule
{
  public CustomRule(Csla.Core.IPropertyInfo primaryProperty)
    : base(primaryProperty)
  {
    InputProperties.Add(primaryProperty);
    IsAsync = true;
  }

  protected async override void Execute(Csla.Rules.RuleContext context)
  {
    var cmd = new LongRunningCommand();
    cmd = await DataPortal.ExecuteAsync(cmd);
    context.AddInformationResult("Rule complete: " + cmd.Output);
    context.Complete();
  }

  [Serializable]
  public class LongRunningCommand : CommandBase<LongRunningCommand>
  {
    public static readonly PropertyInfo<string> OutputProperty = RegisterProperty<string>(c => c.Output);
    public string Output
    {
      get { return ReadProperty(OutputProperty); }
      private set { LoadProperty(OutputProperty, value); }
    }

    protected new async Task DataPortal_Execute()
    {
      Output = "Before delay";
      await Task.Delay(3000);
      Output = "After delay";
    }
  }
}

Notice that the rule’s constructor sets the rule’s IsAsync property to true. This tells the CSLA rules engine that the rule will be async.

Also notice that the rule’s Execute method is marked with the async keyword, allowing the use of the await keyword within the method. In this example, the rule uses the data portal to asynchronously execute a command object by awaiting the ExecuteAsync method.

Because the rule has IsAsync true, the Execute method must call context.Complete to indicate that the rule has finished processing. If you don’t call context.Complete the CSLA rule engine will never process the rule’s result, and you’ll have a bug in your application.

The command object itself also uses the async keyword to implement the DataPortal_Execute method. Notice that this method returns a Task. The server-side data portal components are smart enough to detect when a DataPortal_XYZ method returns type Task, so the DataPortal_XYZ method is invoked correctly.

Within the DataPortal_Execute method I just use Task.Delay to create an artificial delay. This represents some long-running operation such as calling a slow web service, invoking an intensive oData query, or something like that.

The end result is that a business object can attach this CustomRule to a property, and the rule will run asynchronously. This is done in the business class’s AddBusinessRules method.

In your UI you can use helper components such as Csla.Xaml.PropertyInfo to determine that the property is running an async rule. For example, you might use XAML like this in WinRT:

<StackPanel Orientation="Horizontal">
  <TextBox Text="{Binding Path=Name, Mode=TwoWay}"/>
  <TextBlock Text="{Binding ElementName=NameInfo,Path=RuleDescription}" Foreground="Yellow"/>
  <ProgressRing IsActive="{Binding ElementName=NameInfo,Path=IsBusy}"/>
  <csla:PropertyInfo Name="NameInfo" Source="{Binding}" Property="Name"/>
</StackPanel>

The specific XAML syntax is a little different in WPF/Silverlight because the XAML language is more mature there than in WinRT. But the basic concept of building a rich user experience based on an async rule is the same across all smart client platforms.

Tuesday, October 09, 2012 3:59:52 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Thursday, October 04, 2012

I have put CSLA 4 version 4.5 beta 2 online as we continue toward the planned final release of version 4.5 on or before Oct 26.

Version 4.5.3 is available via nuget and from the CSLA download page.

The change log contains a list of all changes. Highlights include:

  1. Substantial changes to CslaActionExtender for Windows Forms
  2. Substantial (and some breaking) changes to pre- and post-processing methods around the data portal
  3. Added the ability to global implement pre- and post-processing handler to server-side data portal to enable logging/tracing and IoC scenarios

At this point we are feature complete, so any releases between now and final release will be bug fixes or stabilization.

Version 4.5 supports the following platforms:

  • .NET 4 (with async targeting pack)
  • Silverlight 5 (with async targeting pack)
  • .NET 4.5
  • WinRT

If you are using any of these platforms, please download and test this new release. Here are some notes regarding upgrading from version 4 to 4.5.

Thursday, October 04, 2012 8:13:38 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Monday, October 01, 2012

I just checked in a series of data portal enhancements that have been on the wish list for a while. Mostly focused on pre- and post-processing behaviors.

The big one is that you can now provide an IInterceptDataPortal provider on the server to get Initialize and Complete notifications for every data portal call, allowing for logging/tracing and IoC scenarios. The logging/tracing is probably obvious, because these methods get a lot of detail about each data portal server invocation and you can do what you’d like with that data. The IoC scenario may be less obvious, but the Initialize method should provide you with a consistent way to create or retrieve your server-side IoC container so it is available for the duration of the server-side processing. I suspect most people will put the container instance in Csla.Application.LocalContext to ensure it is easily and consistently available to all code regardless of runtime environment (ASP.NET, pure .NET, WinRT, Silverlight).

The existing pre- and post-processing calls now all get a lot more data than they did before, so they should be more useful by far. The primary focus was on the Invoke, InvokeComplete, and InvokeException methods in factory objects, where the previous implementation was poor. In that context I did make a breaking change, because those methods are now passed a Csla.DataPortalEventArgs value as a parameter, instead of the more limited DataPortalContext they got before.

While I was doing this change though, I also increased the amount of data provided to the pre and post-processing DataPortal_XYZ and Child_XYZ style methods. So everyone gets an upgrade Smile

Finally, the data portal no longer returns the business object to the client when an exception happens – at least by default. Up to this point the data portal has always returned the business object from the server to the client via the DataPortalException, but almost no one actually uses that value. By not returning it, we save a bunch of network traffic and improve performance. If you want the value, you can configure the data portal to use the older behavior. So this is a breaking change, but one with an easy workaround.

Monday, October 01, 2012 2:26:41 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Monday, September 24, 2012

CSLA 4 version 4.5.2 is now online. This is Beta 1 of the 4.5 release, and is the start of the beta process. I expect to release a number of betas in relatively short order between now and the end of October. My plan is to have a final release before Windows 8 GA.

You can get this beta release from nuget (show unreleased versions), or via the installer from the CSLA download page.

This release supports .NET 4, .NET 4.5, WinRT, and Silverlight 5.

This beta release is a major change over the previous preview releases.

  1. CSLA now fully supports the new WinRT platform for Windows 8 development.
  2. The data portal now supports async/await on the client and on the server. Additionally, the .NET, WinRT, and Silverlight data portal implementations are now the same. There is no longer a “Silverlight data portal”. To make this happen, the data portal pipeline underwent major changes. This includes a number of breaking changes.
  3. The MobileFormatter is now available for use by .NET applications (not just Silverlight and WinRT). This might allow .NET apps to run in partial trust, and certainly allows .NET apps to use the same data portal channel/endpoint  as a WinRT or Silverlight app.
  4. Jonny has done a lot of work on the business rules engine. There shouldn’t be any real breaking changes, but there are a lot of good new features.
  5. BusinessBase metastate properties (such as IsDirty) are now bindable – they raise PropertyChanged as you’d expect. This enables some XAML scenarios, but be careful because WinRT XAML doesn’t notice when the DataContext has changed, so you can run into some strange issues when saving an editable object in WinRT.
  6. Johann put a lot of work into the nuget release process, allowing us to use nuget for prereleases like this one, and to create a nuget package with code templates for use in your projects.
  7. We now support .NET 4.5 and 4.0 with CSLA 4.5, so you can use the same CSLA 4.5 on existing .NET 4 machines, on Windows Azure, and also use it on .NET 4.5 machines. A 4.5 client can talk to a .NET 4 server and visa versa.
  8. WinRT now includes language resources.
  9. A number of changes were made to the Windows Forms CslaActionExtender type.

Be aware that the .NET 4 and Silverlight 5 environments now require that you use the Async Targeting Pack from Microsoft (typically via nuget) so that CSLA and your code can use the async/await keywords and related functionality.

Be aware that the data portal has breaking changes, especially for Silverlight users. Some highlights of breaking changes:

  • The Enterprise Services, Remoting, and asmx data portal channels have been removed. If you need these wire transport technologies you can create your own proxy and host types based on the version 3.8 code (perhaps they’ll end up in CslaContrib at some point).
  • The namespaces for proxy and host types that included “Silverlight” in the namespace now use the term “Mobile” instead. For example, Csla.Server.Hosts.IWcfPortal is now Csla.Server.Hosts.Mobile.IWcfPortal.
  • The client-side ProxyMode concept is now eliminated entirely, and you should use the same RunLocal attribute in Silverlight as you do in .NET.
  • All client-side DataPortal_XYZ methods in Silverlight are now different, and no longer accept a callback handler parameter. Instead, code all client-side DataPortal_XYZ methods for Silverlight just as you would for .NET.

Please direct any comments, suggestions, bug reports, or other feedback to the CSLA forums.

Monday, September 24, 2012 2:16:59 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
On this page....
Search
Archives
Feed your aggregator (RSS 2.0)
July, 2014 (3)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)
Categories
About

Powered by: newtelligence dasBlog 2.0.7226.0

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2014, Marimer LLC

Send mail to the author(s) E-mail



Sign In