Update 10/2016 - This posting is better viewed in my new blog . Background In a post two years ago I expressed my admiration of ClickOnce. At the time we'd experienced years of tremendous success using it as our client application's primary deployment mechanism and since that time it has not faltered. I now regret to say that over the last year I've seen evidence that makes me question continued reliance on ClickOnce. I think its life-cycle may be coming to end. Though that saddens me I understand that in the tech world all technology is transient and the best ideas don't always last as long as they should (see Silverlight). Data, however, must continue flowing. About eight months ago I started searching for alternative deployment mechanism which might provide some of the benefits we'd leveraged with ClickOnce. That search came up mostly wanting. However, one candidate identified was the open source project Squirrel.Windows . The moniker on the GitHub proj...
Update 10/2016 - This posting is better viewed in my new blog . Let me start by stating, emphatically: I LOVE CSLA .NET ! I first became aware of this excellent framework in 2008 when my boss dropped Rocky's book Expert C# 2008 Business Objects on my desk. In very short order I recognized the enormous benefits CSLA could provide to developers like myself who where trying to to produce great enterprise applications. The idea that I could create completely self-contained classes which would flow naturally between the various application layers and physical tiers made me fairly giddy with excitement. This excitement was reinforced by my efforts as I implemented user presentation layers for WinForms, WPF and Silverlight all based on the same business core with little impedance between the architectural layers or the physical tiers. Concerns such as validation and n-level undo were mostly handled by the CSLA framework with very little additional effort from the developer (me). ...
Update 10/2016 - This posting is better viewed in my new blog . I have a Web API project which leverages an SQL database through Entity Framework. Pretty standard Microsoft technology stacks I've been using for years. When using EF I've historically disabled lazy loading and proxy generation due to lack of need for those features. This project I left them enabled. I quickly started getting serialization exceptions from my controller. A little googling and I found this is a known issue with the use of EF dynamic proxies and serialization (specifically JSON). Infinite reference loops can and often do appear in EF entities. Take the following example. public class Parent { public ICollection<Child> Children { get ; set ; } } public class Child { public Parent Parent { get ; set ; } } A Parent has references to many Children and each Child has a reference to the Parent. An infinite loop occurs when the serializer attempts to fully resolve either of ...
Comments
Post a Comment