Crashing your LightSwitch project with your extensions is a piece of cake. The first simplest thing I did was change the business type to handle integer values instead of string ones. But I changed “:String” to “:Int”. That was enough to do it. It should be “:Int32”.

So, after managing to create and use (declare as a type for an integer field in an entity) my business type, keeping my LightSwitch project in one piece, I had to work on my control. As I have already mentioned I had my custom control ready and tested, so, it should be easy.

I had used my custom control only in detail parts and although the expander used was “deforming” the layout when expanded (I have to fix this anyhow in the future) everything were going back to normal after collapsing the expander. This was not so for collections. Using my control in a grid the result after collapsing the color picker control was a grid row having a height of the expanded control. The reason is that the grid rows are auto-sized and have no specific...

I haven’t been able to post during the last week. It’s been a very hectic week and I didn’t have time or when I did have the time I didn’t have the courage…

Anyhow, I am going to share with you issues I had to face creating my first LightSwitch Extensions project.

First thing was to create the Color business type. I already had custom Silverlight control and value converters I had already published in a sample in MSDN’s LightSwitch Developer Center. So half of the work was done, right? Well, not quite…

I must say here that many of the problems were a result of the fact that editing the lsml file is very error prone as there is nothing to help you while editing the file by hand. I mean it’s not like editing the XAML of a Silverlight control, with code completion, syntax checking and all the goodies. It’s raw XML editing. And the thing with errors in lsml is that the result is terrifying…a tag improperly...

I had initially discarded LightSwitch from my deck of choices. At first glance (early Beta 1) I had misjudged it as poor relative of application builders that I hate altogether.

It was after watching Beth Massi’ s presentation in Tech-Ed USA 2011 regarding extensibility that made me take a second good look at it. And then…then it was love at second sight...

This is my approach to making screen authorization (show/hide) more effective and robust that hard-coding permission names in the “_CanRun” partial methods. The library and sample code is published here. As with my previous post the code is posted to msdn and here I will explain in detail how to use the library and what the sample does.

First let’s prepare. After downloading the sample and before you can run you must create a database I use for storing screen security information. Create a database named LSSecurity and then open and execute the script found in the zip at the path Files\LSSecurity.script.sql. Then you have to go to your ServerGenerated\Web.Config and change the connection string from localhost\clcadlocal to the name of your SQL server. This database is imported by the sample Lightswitch application in a datasource called LightSwitchSecurity. The entities from this datasource are used to implement...

Immediately after using Excel Importer extension for the first time and trying to see how this would fit into our new “want to be” business application framework, I realized that defining the column mappings every time was definitely an issue.

So I decided to implement and integrate to the original Excel Importer a mechanism for using Column Mapping Templates as an optional capability. I decided to give it back to the LightSwitch community, where the original idea (msdn.com Lightswitch Samples) came from. You can download the the extension here. Feel free, no better yet, feel obliged , ...