Rockford Lhotka's Blog

Home | | CSLA .NET

 Wednesday, June 01, 2016

csla win8_fullThis release of CSLA .NET is focused primarily on enhancing the existing Xamarin support. There is now a Csla.dll targeting PCL Profile111, which is the current profile for Xamarin.Forms projects and .NET Core.

There is also now a CSLA-Xamarin NuGet package that includes a Csla.Xaml.dll with support for Xamarin.Forms. This includes the same viewmodel base classes as the other XAML platforms, and an implementation of the PropertyInfo control tailored for use in Xamarin.Forms.

@JasonBock added even more analyzers for Visual Studio 2015 to help developers avoid common coding mistakes when building CSLA .NET business classes.

We now have support for the prerelease of Entity Framework 7.

The pt and pt-BR resources for Csla.dll have been updated. Other languages need updates as well - please contribute if you are a native speaker!

There is a new way to customize the server-side data portal by implementing an interceptor that is invoked via the new DataPortalBroker. (#564)

Full details:

The assemblies and packages are all available via NuGet.

Wednesday, June 01, 2016 9:33:18 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, May 26, 2016

th7JTBT6D7There is now a Csla.Xaml.PropertyInfo control for Xamarin Forms as well as WPF/UWP, so you can use the same technique to access all metastate about each property from your XAML.

This means that (now on Xamarin too) you can bind to the property value, as well as CanRead, CanWrite, IsValid, IsBusy, and various other metastate values.

Using this capability your XAML UI can provide the user with immediate and rich visual cues as to whether the user is allowed to read or write the property value, and whether the current property value is valid (and if not, why), as well as whether the property has any outstanding async business rules currently executing.

In short, all the goodness that WPF/Silverlight/UWP developers have enjoyed over the past many years is now available on Xamarin!

(or will be once CSLA .NET 4.6.400 releases in about a week – though you can try it now with the 4.6.400 prerelease available via NuGet)

Thursday, May 26, 2016 3:57:07 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, May 25, 2016

The CSLA PCL that supports Xamarin includes an implementation of System.ComponentModel.DataAnnotations, and that includes numerous types, one of which is DisplayAttribute.

The PCL uses type forwarding so at runtime the platform's DataAnnotations implementation is used (if available), and the CSLA implementation is only used at runtime for platforms where there's not already an implementation (WinRT Phone is the only remaining platform afaik).

There is a problem with Xamarin however, where all types seem to forward and work fine except for DisplayAttribute. The problem in this case is that at runtime it seems that mono is unable to locate the correct ctor for the type:

"System.MissingMethodException: Method 'DisplayAttribute..ctor' not found.\n  at (wrapper managed-to-native) System.MonoCustomAttrs:GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool)\n  at System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType, Boolean inheritedOnly) [0x00019] in /Users/builder/data/lanes/3236/ee215fc9/source/mono/mcs/class/corlib/System/MonoCustomAttrs.cs:128 \n  at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) [0x00040] in /Users/builder/data/lanes/3236/ee215fc9/source/mono/mcs/class/corlib/System/MonoCustomAttrs.cs:158 \n  at System.Reflection.MonoProperty.GetCustomAttributes (System.Type attributeType, Boolean inherit) [0x00000] in /Users/builder/data/lanes/3236/ee215fc9/source/mono/mcs/class/corlib/System.Reflection/MonoProperty.cs:317 \n  at Csla.Core.FieldManager.DefaultPropertyInfoFactory.GetFriendlyNameFromAttributes (System.Ty
pe type, System.String name) [0x00011] in <filename unknown>:0 \n  at Csla.Core.FieldManager.DefaultPropertyInfoFactory.Create[T] (System.Type containingType, System.String name) [0x00000] in <filename unknown>:0 \n  at Csla.ReadOnlyBase`1[T].RegisterProperty[P] (System.Linq.Expressions.Expression`1 propertyLambdaExpression) [0x0001c] in <filename unknown>:0 \n  at ProjectTracker.Library.ProjectInfo..cctor () [0x00000] in G:\\src\\rdl\\csla\\Samples\\ProjectTracker\\ProjectTracker.BusinessLibrary.Shared\\ProjectInfo.cs:10 "

This exception occurs when the consume app attempts to access the DisplayAttribute associated with a property to retrieve values from the attribute. It appears that mono is unable to create an instance of the attribute object because it can't find the ctor. The DisplayAttribute class has only a default ctor, but is typically initialized using named parameters, such as:

[Display(Name = "foo")]

I don't know what kind of ctor mono is looking for when it fails, but it obviously isn't finding the default ctor and then setting the property value, which is what would be the expected behavior.

I’m tracking this issue in the CSLA GitHub repo:

Steps to reproduce issue

The CSLA ProjectTracker reference app in my fork includes a repro of this issue. To see the issue, do the following:

  1. Clone my fork of CSLA from
  2. Checkout the 505-xamarin branch:
  3. Open the \Samples\ProjectTracker\ProjectTracker.sln solution
  4. Build the solution – it’ll pull down the CSLA .NET framework from NuGet
  5. Set a breakpoint in the XamarinFormsUi.ViewModels.ProjectList class as shown here
  6. Set the startup app to ProjectTracker.Ui.Xamarin.Droid
  7. Run the app in debug mode (on an emulator or device)
  8. On the first screen click the All Projects button

That’ll attempt to load the ProjectList page and ProjectList viewmodel. At this point the exception will occur and you’ll end up on the breakpoint because of the failure to create an instance of ProjectInfo, but that fails because mono can’t create an instance of DisplayAttribute (used on some properties in the ProjectInfo class).

Wednesday, May 25, 2016 12:51:26 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, May 20, 2016

I might have found a bug in mono, but want to see if anyone thinks I'm missing something.

The CSLA .NET framework has long included an implementation of the System.ComponentModel.DataAnnotations namespace for platforms where Microsoft/Xamarin didn’t provide that functionality. These days I think that is only Windows Phone 8.1, but that includes PCL Profile111 (which is what Xamarin currently targets as well).

Of course the CSLA implementation includes the DisplayAttribute class, which is used to decorate properties in consuming classes like this:

[Display(Name = "blah")]

That "blah" value is a human readable name/label for a property.

Because mono actually provides a System.ComponentModel.DataAnnotations implementation, my PCL uses type forwarding so at runtime the PCL implementation is ignored in favor of the platform-specific implementation provided by mono. For example:

[assembly: System.Runtime.CompilerServices.TypeForwardedTo(typeof(System.ComponentModel.DataAnnotations.DisplayAttribute))]

This works great on all platforms - except Xamarin Android/iOS where mono throws an exception because it can't find a matching constructor.

The thing is that the DisplayAttribute class has only the default constructor. The syntax being used to set the Name property of the attribute is supposed to use the default ctor, and then the Name property is explicitly set. This is a relatively old feature of C# - but I kind of suspect mono has a bug around this area, as it seems to be looking for a ctor that accepts a parameter when it should use the default ctor.

Friday, May 20, 2016 3:40:28 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, February 24, 2016

thFZCMG746th0KQMQKB6By now nearly everyone is aware that Microsoft is acquiring Xamarin, and from what I can see nearly everyone is ecstatic!

If you missed it, here are a couple important blog posts:

I am generally positive on this, with the same reservation I’ve had since rumors of this idea came up a couple years ago: Xamarin has been able to navigate and maintain good relationships with Apple and Google (and others) for some years now – releasing support for those platforms concurrent with Apple and Google releasing new versions of those platforms. It may be difficult for Microsoft to maintain comparable relationships with Apple and Google over time, because they aren’t a scrappy startup, they are a peer.

On the upside, what I hope comes out of this includes:

First, rolling Xamarin directly into Visual Studio, thus making it part of my existing MSDN subscription. Just think about the consequences if everyone who has an MSDN subscription (so everyone with Visual Studio 2013/2015 today) can all of a sudden build cross-platform .NET apps for Windows, iOS, Android, and OS X – at no additional cost.

One big thing holding Xamarin back in terms of widespread adoption is its cost. At $2k/developer it is prohibitive for a lot of scenarios, and that has been driving people to less productive and robust tools such as Cordova. But if we all get cross-platform .NET as part of our existing MSDN that radically changes the equation – in a way that favors the use of .NET.

Second, enabling Microsoft to provide UWP (XAML and APIs) on iOS, Android, and OS X. The “U” in UWP is “Universal” – and that’d have a lot more weight if it meant all the popular smart client development targets available today, not just the Microsoft ones. I imagine such a UWP would replace Xamarin Forms with the same XAML dialect we see on Windows 10 and Windows 10 Mobile, and obviously there’d need to be some serious work in creating WinRT API support (yes, WinRT “2.0” is really what’s underneath UWP) for these other platforms – so we won’t see this overnight – but the long-term implications are amazing.

Microsoft’s biggest single problem, especially on Windows phones, but also on Windows 10, is getting high quality apps that target these platforms. A truly universal UWP might help this problem by making .NET/UWP become the single most cost-effective way to build any smart client cross-platform app.

On the whole I am quite happy and excited – congratulations to the Microsoft and Xamarin people who put this together!

Wednesday, February 24, 2016 3:16:56 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, July 14, 2014

From around 1995 until 2010 there was really only one operating system for client computing: Windows.

Prior to 1995 there were a lot of options, though most not recognizable to users today: 3270 terminals, VT terminals, OS/2, Windows, DOS, CPM, and a bunch of others. Now most of these weren’t “client computing”, they were relatively dumb terminal technologies that provided access to a server (back then called a mainframe or minicomputer). Very much like today’s web browser (sans JavaScript).

Today we’ve returned to a chaotic landscape of client computing: browsers, Windows, iOS, OS X, Android, Linux (for the daring), and of course it isn’t like the pre-1995 technologies went away, they are just mostly emulated in Windows. What is interesting though, is that most of today’s client computing technologies do actually enable smart client software development. This includes the browser which can be used as a smart client technology via JavaScript development, even though the majority of browser “apps” are actually just colorful versions of 1990-era terminal-based computing where the processing is all on a server/mainframe/minicomputer/whatever-you-want-to-call-it.

What is interesting about this return to client-side chaos is that it has reopened the door for third party developer tools as a niche market.

In the early 1990’s there were quite a number of companies selling developer tools for other company’s platforms. Borland with C++, Delphi and TurboPascal, Gupta with SqlWindows, Powerbuilder, and a lot more.

When Windows became the dominant client computing platform most of these dev tools fell by the wayside (not that they went away, they just stopped being mainstream). This was because they couldn’t compete with Microsoft’s dev tools, which were always in sync with the platform in a way that was probably too expensive for third parties to match.

I think it is notable that our return to client computing chaos (or pluralism?) today has already led to numerous third party dev tool vendors that sell dev tools for other company’s platforms. Xamarin, PhoneGap, Telerik’s tools, and a lot more.

What is different to me is that in the early 1990’s I thought it was pretty obvious that Windows would become a dominant platform, and I tended to argue against using third party dev tools because I thought they’d have a rough go of it. As cool as Delphi was, I always recommended VB.

Today I’m not so sure. I don’t see any of today’s platforms becoming dominant in the foreseeable future. It is hard to imagine Windows returning to its monopoly status, but I can’t imagine iOS or Android or OS X displacing Windows as the primary corporate desktop computing environment either.

As a result we business developers need some way to build software independently of any particular platform or OS vendor, because we must assume all our business software will need to run on multiple platforms and OSes.

So today I find myself in the inverse of my early 1990’s stance, in that I’m reasonably convinced that building smart client software (at least for business) means using third party dev tools from vendors that aren’t tied to any one platform.

Of course I’ve spent the last 14 years in the .NET world, so naturally I gravitate toward a combination of Xamarin and Microsoft .NET as a way to use my C# and .NET knowledge across all platforms. I get to develop in Visual Studio on Windows where I’m most comfortable, and my resulting software runs on Android and iOS as well as on Windows Desktop, Phone, and WinRT.

As far into the future as I can see there’s no obvious platform/OS “winner”, so as a developer the question isn’t which platform to target, it is which third party dev tool reaches all platforms with a solid strategy that will stand out and thrive over the next many years.

Monday, July 14, 2014 1:00:31 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, July 01, 2014

There’s been a lot of exciting change in cross-platform development for C# developers over the past few months. Microsoft introduced the Universal Apps concept for WinRT (Windows 8 and Windows Phone 8.1), and Xamarin introduced Xamarin.Forms (Windows Phone 8, Android, and iOS).

Beneath the Universal App support in Visual Studio 2013 is a broader concept called a Shared Project. With the Shared Project Reference Manager add-in for VS13 you can reference these shared projects from any project, not just Universal App projects.

As a result, you can build a solution like this one:


This solution includes a Xamarin.Forms MobileApp, a Microsoft Universal App (based on the Hub control), a Windows Forms app, and a WPF app. All of these apps use non-UI code from the NonUICode.Shared project.

In fact, the Android, iOS, WinPhone, Windows, and WindowsPhone UI projects have basically no code at all. In the MobileApp all the UI code is in the MobileApp1.Shared project. In the WinRTApp all the UI code is in the HubApp1.Shared project.

The Windows Forms and WPF apps each have their own UI code. Windows Forms is its own thing, and although WPF uses XAML, it is an older dialect that doesn’t share enough in common with WinRT or Xamarin.Forms for sharing.

None of the UI projects contain any business logic or logic to call services. All that code is in the NonUICode.Shared project so it can be maintained just one time. The service calls use HttpClient, which is reasonably common across all the UI platforms, and for the few differences I’m using #if statements to accommodate the per-platform code. For example, here’s a bit of code from a shared viewmodel class: 

    public async Task SaveData()
      if (this.IsDataLoaded)
        var webClient = new HttpClient();
        var data = JsonConvert.SerializeObject(this.Speaker);
#if ANDROID || __ANDROID__ || __IOS__
        var content = new StringContent(data, System.Text.Encoding.UTF8, "application/json");
        var content = new HttpStringContent(data);
        var urlString = apiSpeakerUrl + @"/" + this.Speaker.Id.ToString();
        var response = await webClient.PutAsync(new Uri(urlString), content);
        if (!response.IsSuccessStatusCode)
          throw new Exception("SaveData failed");

The overall result is that with reasonable effort you can create an app that spans every type of smart client technology available today; from Windows Forms up to iOS. These apps can share all your business and service client code, and can often share a lot of UI code.

(fwiw, if you build your business logic with CSLA .NET it is a lot easier to create and maintain the shared business and service client code than if you try to build that code by hand)

CSLA .NET | WinRT | WP8 | Xamarin
Tuesday, July 01, 2014 3:32:53 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, June 18, 2014

A couple of us at Magenic have been spending some time looking into the new Xamarin.Forms technology.


It has some nice potential, but is clearly at the prototype stage more than the ready-for-use stage.

The good potential centers around the start of a XAML dialect they’ve created that describes common UI elements and concepts across iOS, Android, and Windows Phone 8 (Silverlight). Using this dialect you can’t get at all the features of each platform, but you can get at enough features to create standard data entry and data viewing forms like you’d need for a typical business application. And there’s always an easy escape hatch that allows you to build per-platform forms for when a common form just isn’t enough.

The bad points are areas I hope they’ll address soon so the technology becomes more useful for real work.

The first roadblock is the almost complete lack of documentation or samples showing how to use their XAML dialect. They have samples showing how to build forms in C#, but not in XAML. It reminds me of the first few months when Microsoft introduced XAML for WPF.

Perhaps it is because of the lack of XAML samples/docs, but it is a real struggle to figure out how to do things like async loading of data, full implementations of data binding against standard data binding types, etc.

I think this whole thing has potential. WPF was really rough when it was introduced, and eventually Microsoft improved the docs and samples and designer tools. And they eventually smoothed over the most egregious data binding issues, allowing the vast majority of existing .NET types to bind into WPF.

I really hope Xamarin does the same thing with this technology.

Wednesday, June 18, 2014 9:45:08 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

csla win8_full This release adds the following key features:

  1. Support for iOS
  2. Support for WinRT on Windows Phone 8.1
  3. Support for Universal Apps that target WinRT on Windows 8.1 and Windows Phone 8.1
  4. A new HttpProxy/Host data portal channel that doesn't rely on WCF
  5. A new BrokeredProxy/Host data portal channel that allows a WinRT (Win8) app to call a local data portal running in full .NET

Here is the version 4.5.600 change log.

You can download the msi installer from the release page, or better yet add references to the framework via NuGet.

Version 4.5.600 includes support for iOS (via Xamarin) and for WinRT on Windows Phone 8.1 in the WinRT.Phone project. This also means you can use the new Universal solution/project type to build WinRT apps for Windows 8.1 and Windows Phone 8.1.

This prerelease also includes the new HttpProxy/Host and BrokeredProxy/Host data portal channels.

The Http data portal channel allows you to host the data portal server directly in ASP.NET MVC 4 or MVC 5 without the need for WCF. It relies only on the HttpClient library to invoke the server, so the client has no dependency on WCF - important for the new Windows Phone 8.1 programming model where WCF doesn't exist.

The Brokered data portal channel allows you to host the data portal server in .NET as a brokered assembly, thus available to a WinRT client app. This means you can build a WinRT app that makes data portal calls, where the "server-side" code is also running on the client device, but has access to full .NET. This will only work on Intel-based devices where full .NET assemblies can be deployed. It will only work with side-loaded apps, not apps from the Windows Store.

CSLA .NET | WinRT | WP8 | Xamarin
Wednesday, June 18, 2014 2:34:52 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, April 28, 2014

As well all know, portable class libraries are pretty cool, but are restricted by the “lowest common denominator” effect.

For example, CSLA .NET supports the use of DataAnnotations along with the richer CSLA rules engine.

In trying to create one of the new “Universal PCL” assemblies to support WinRT on Win8 and WP8 I ran into the fact that WP8 doesn’t support DataAnnotations.

“No problem” I thought, “we already have our own implementation for WP8 Silverlight, for Android, and for iOS. I’ll just use that code.”

Which worked insofar as that I have a Universal PCL Csla.dll that builds.

But it doesn’t work because I can’t actually use that Csla.dll from WinRT on Win8 because that WinRT already has DataAnnotations and so there are type collisions.

As a result it isn’t clear to me that I can actually create a Universal PCL for CSLA – at least not one that supports DataAnnotations across all platforms like I’m able to do if I create one assembly per target platform (like I’ve been doing since 2007 with Silverlight 2).

I guess this makes sense. The guidance around creating a PCL is that you have code that is simple enough that it doesn’t include any platform-specific implementations that would be solved easily using #if directives. The internal implementation of some parts of CSLA is far from simple, and we do use #if directives to optimize for and/or leverage features of each of the 9 platforms currently supported by CSLA (yes, we really provide business code portability across NINE different platforms).

My personal feeling is that I’d rather support all 9 platforms as efficiently as possible, rather than compromise one or more of them just to use a fancy and optional new concept like the Universal PCL.

(of course if Microsoft and Xamarin add DataAnnotations to Windows Phone 8.1, Android, and iOS then I wouldn’t need to implement it in CSLA and that would also solve this problem – so maybe someday :) )

Monday, April 28, 2014 2:07:47 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, March 17, 2014

I just created a release of CSLA 4 version 4.5.580-Beta with preliminary support for iOS via the Xamarin tools.

You can get it via nuget (easiest), or from the release page on GitHub.

This is an exciting pre-release because it now means you can reuse the same business logic code across all modern app client platforms and the desktop and the cloud. This is a “who’s who” list of supported platforms:

  • iOS
    • iPad
    • iPhone
  • Android
    • Phones
    • Tablets
  • Windows
    • WinRT (Windows 8)
    • WPF
    • Silverlight
    • Windows Forms
  • Windows Phone
  • Cloud and servers
    • Windows Azure
    • Windows Server
    • ASP.NET (MVC and Web Forms)
    • WCF
    • Web API
  • Linux
  • OS X

CSLA .NET allows you to easily create reusable business logic (authorization, validation, calculations, etc.) and to share a common app server with simple network configuration. I don’t know of any other open source C# framework that makes it possible for you to reuse the exact same business logic across all these different platforms.

Because the iOS support is new we are asking for your help. If you have the Xamarin tools for iOS please help us out by building some business code using CSLA and let us know if you find any issues (either on the forum at or via the CSLA GitHub page.

Monday, March 17, 2014 10:42:21 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
On this page....
Feed your aggregator (RSS 2.0)
August, 2016 (4)
July, 2016 (2)
June, 2016 (4)
May, 2016 (3)
April, 2016 (4)
March, 2016 (1)
February, 2016 (7)
January, 2016 (4)
December, 2015 (4)
November, 2015 (2)
October, 2015 (2)
September, 2015 (3)
August, 2015 (3)
July, 2015 (2)
June, 2015 (2)
May, 2015 (1)
February, 2015 (1)
January, 2015 (1)
October, 2014 (1)
August, 2014 (2)
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)

Powered by: newtelligence dasBlog 2.0.7226.0

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

© Copyright 2016, Marimer LLC

Send mail to the author(s) E-mail

Sign In