Build a Lightswitch App without using the designer

Question

I'm a programmer. Whilest I can use  the "Write Code" dropdown to insert code blocks into the Application, ApplicationDataService, EntityObject<T> and ScreenObject<T> classes, I would like the ability to define entites, screens, relationships and queries through code / markup / a DSL.

Obviously Lightswitch meta-programs this when I use the designer, but I would lke to do it myself. I've been reflecting over Microsoft.Lightswitch.dll - can you give me some pointers as to how to accomplish this?

 

Answer 1

Hi,

The answer is that you can't - and shouldn't need to. The idea behind LightSwitch is that all of the plumbing and UI code is done for you; the only code you need to write is the business logic unique to your situation.

For an experienced programmer, LightSwitch can be difficult to get used to. At first I found myself dropping into code to do things (and getting frustrated), only to find out later that I didn't need to write code to do what I was trying to do. What exactly are you trying to accomplish? Perhaps there is already a non-code way of doing it, and if not, perhaps your feedback may point out a scenario that we hadn't considered.

Regards,

---

Steve Hoag Microsoft aka the V-Bee

Answer 2

What I would like to accomplish is to create a lightswitch app - without having to click through a tool or designer.

I really like the Ria Services approach, and I see Lightswitch as the next higher level of abstraction, but my scenario is this:  

I need to be able to define a Lighswitch app without having to rely on the designer and tedious click-throughs. If I have access to the API that the designer uses, then I can automate application generation, I can parameterize it and apply custome logic for generating custom variations of the same application type,  I can even wrap it within a DSL. As a programmer, I want to levarge Lightswitch for developing applications by meta-programming.

In Lightswitch, the pieces are obviously there (the designer leverages them), but they are not exposed as a public API.

Can I do this with Beta 2? if not can you point out to me which DLLs and which classes the designer uses for code generation?

Regards,

Josh Reuben [e-mail]

Answer 3

Because LightSwitch is essentially a plug-in for Visual Studio, it's "Model Centric" development workflow using the "tedious click-thoroughs" "is" the product :)

However, you can produce custom variations using:

• Custom Themes
• Custom Shells (The exact same LightSwitch application with a different UI (should be in the next Beta))
• Custom control plug-ins (like the Bing maps)

---

http://www.adefwebserver.com

http://lightswitch.adefwebserver.com

Answer 4

I am aware of the skinning functionality (custom themes, shells, controls) ; it is insufficient for my needs.

being a plugin for visual studio, perhaps there is a VSIX API extension I can leverage for automating Lightswitch?

I repeat my scenario requirements: I need programmatic access to the API underlying the Lightswitch designer,  in order to automate Lightswitch application generation (ie metaprogramming).

Answer 5

Hi Josh,

I understand your scenario. It is not something that we are supporting in LightSwitch, at least not in V1.

Regards,

---

Steve Hoag Microsoft aka the V-Bee

Answer 6

I repeat my scenario requirements: I need programmatic access to the API underlying the Lightswitch designer,  in order to automate Lightswitch application generation (ie metaprogramming).

It is clear "what" you desire, but I think the LightSwitch team would really be interested in "why".

For example, I came to them and indicated that I want to deploy LightSwitch in a DotNetNuke site. That was the "what". The "why" was that the DotNetNuke site already has other modules that are deployed into the website and they have data that the LightSwitch app needs to talk to. The end user already knows how to use a wizard to install modules.

The team was then able to point out that the package that LightSwitch creates can be used to make a DotNetNuke package.

So, they probably want to know who is the "end client", and what is the work flow you are thinking about?

---

http://www.adefwebserver.com

http://lightswitch.adefwebserver.com

Answer 7

Pretty cool.  Josh let us know that he wants to: 

   "automate LightSwitch application generation (ie metaprogramming)"

I would guess that the "why?" is that Josh has an idea to go to higher levels of automation than the exsiting toolset.

This seems reasonable.   There are systems such as DX XAF, Aptify, and a few more (that I'm not comfortable discussing in this forum) that generate applications based on their design systems.   For example, our company has an application generator that we wrote in the mid-80s for Unix using C++.  It would be great to be able to gen LS and SL apps based on our databased app gen.

.NET and Visual Studio is all about extensibility.

Computers and software are still in the infancy stage.  It will probably be a lot more interesting in a few hundred years.

Josh's post here has sparked my interest.  I'd also like to hear more from Josh and others of a similar mindset.

Answer 8

Pretty cool.  Josh let us know that he wants to: 

   "automate LightSwitch application generation (ie metaprogramming)"

I would guess that the "why?" is that Josh has an idea to go to higher levels of automation than the exsiting toolset.

This seems reasonable.   There are systems such as DX XAF, Aptify, and a few more (that I'm not comfortable discussing in this forum) that generate applications based on their design systems.   For example, our company has an application generator that we wrote in the mid-80s for Unix using C++.  It would be great to be able to gen LS and SL apps based on our databased app gen.

.NET and Visual Studio is all about extensibility.

Computers and software are still in the infancy stage.  It will probably be a lot more interesting in a few hundred years.

Josh's post here has sparked my interest.  I'd also like to hear more from Josh and others of a similar mindset.

I would be surprised if this would ever be a priority. LightSwitch "is" the Visual Studio designer.

However, if another Microsoft product wanted to create a "LightSwitch output" (perhaps Excel could output a LightSwitch package) I could see how they could be compelled to move it up as a priority.

However, I just re-watched the video with Steve Anonsen and John Rivard and they point out that once they expose an API it cannot be changed. So the chances of getting them to commit to anything before v2 is about zero :)

---

http://www.adefwebserver.com

http://lightswitch.adefwebserver.com

Answer 9

We automate lightswitch (the product) internally when we do automated testing.  However, this is bringing up the full VS experience, you see text flying into textboxes in the designer, etc.

To my knowledge, we're not using any special hooks or capabilities to test the product in this fashion.

So the point is -- it's certainly possible.  In the olden days you could automate almost any MS software by driving it at the MSAA layer.  In LS we actually have interfaces 1 level below the UI that we primarily work against.

But this is not something that is a supported scenario, there will probably never be documentation on it, and I certainly can't envision a blog post describing it -- our test libraries are tens of thousands of lines of code :)

You asked if it was possible.  A version of what you want is possible and exists.  We have an open software tester position on our team, if you'd like to come use it :)

 

Answer 10

We automate lightswitch (the product) internally when we do automated testing.  However, this is bringing up the full VS experience, you see text flying into textboxes in the designer, etc.

To my knowledge, we're not using any special hooks or capabilities to test the product in this fashion.

So the point is -- it's certainly possible.  In the olden days you could automate almost any MS software by driving it at the MSAA layer.  In LS we actually have interfaces 1 level below the UI that we primarily work against.

But this is not something that is a supported scenario, there will probably never be documentation on it, and I certainly can't envision a blog post describing it -- our test libraries are tens of thousands of lines of code :)

You asked if it was possible.  A version of what you want is possible and exists.  We have an open software tester position on our team, if you'd like to come use it :)

 

Matt I do not know if you will recall this but around the time that VS 2005 came out MS PAG group and others were talking about "Software Factories" and building DSL's to work with Meta-Data that could build parts of systems and applications w/o coding.

In a number of ways LightSwitch is one realization of that dream.

EF 4.0 and many of the tools in VS today bring us close to it also.

while i agree that what the OP asks for is beyond the scope of LS V1 he does have some valid points to what he is asking about.

I wonder if some tool might create a new LS solution and some files that go into the solution and then invoke a build.

not run the whole GUI, just a batch build of a valid soultion folder and files.

 

Answer 11

So the code exists but is not exposed. Most medium sized projects are tens of thousands of lines of code - each operation must have an entry point. Can you point out where the code is? Is it managed code, COM or unmanaged C++ ?

Answer 12

This is not something that we are supporting in LightSwitch V1. As Matt pointed out, we do have a test harness for automating parts of LightSwitch. That test infrastructure took thousands of man-hours to create, and still requires dozens of engineers to maintain. Even if you were able to define entities, screens and queries through metaprogramming, if we change parts of the underlying APIs in a later version it would likely break your tool.

Perhaps a better way to accomplish what you want is to do as much as possible on the back end to create entities, relationships and queries. Through extensibility you should be able to define your own standardized set of screens. At that point, all that it takes is plugging the pieces together in LightSwitch - something that is already pretty easy, IMHO.

Regards,

---

Steve Hoag Microsoft aka the V-Bee

Answer 13

http://social.msdn.microsoft.com/Forums/en-US/lightswitchgeneral/thread/df4dcc77-aeec-4965-af93-bbadcbe61c18

What would prevent me from using my own T4 to generate Data\ApplicationDefinition.lsml  , GeneratedArtifacts\Application.cs and  Screen.cs ?

Answer 14

http://social.msdn.microsoft.com/Forums/en-US/lightswitchgeneral/thread/df4dcc77-aeec-4965-af93-bbadcbe61c18

What would prevent me from using my own T4 to generate Data\ApplicationDefinition.lsml  , GeneratedArtifacts\Application.cs and  Screen.cs ?

They will change the .lsml spec and all your code will break.

That is basically the issue. They do not want to publish a .lsml spec and promise that it wont change. It is not in their best interest to tie their hands at this point.

---

http://www.adefwebserver.com

http://lightswitch.adefwebserver.com

Answer 15

judging from the comments on connect.microsoft.com, I am not alone in desiring this core functionality! 

https://connect.microsoft.com/VisualStudio/feedback/details/587810/should-lightswitch-be-able-to-generate-application-code-via-t4-not-just-applications?wa=wsignin1.0

Answer 16

No, you aren't alone, and our architects do see this as a valid scenario - just not for V1. The Connect thread was resolved as "by design". We will not support T4 code generation in LightSwitch V1.

---

Steve Hoag Microsoft aka the V-Bee

Answer 17

I can also see the value in the point being made here by the OP.

The "problem" seems to be that the original intent was for LightSwitch to be for non-developers, people for whom using a designer & multiple "clicks" to get simple things done makes sense. We of course often find that kind of thing "tedious".

What I think has surprised the team is that so *many* developers have seen the potential of what it can do for us as well, & are wanting to adopt it into their "bag of tricks", so to speak.

Naturally we're going to want to push the bounds much harder than the original intended consumers of the product. I hope we'll be able to do this, if not in LS V2, then in a "big brother" type product (LS Pro?) that *will* be targetted specifically to developers.

LS does some *amazing* things already, we of course, just want to be able to do "more". I certainly get the reasons for the resistance, even if I wish it weren't so personally. But I see no reason why "how to manipulate the lsml" directly couldn't be exposed, on the proviso that anyone using it understands that tools made to do so may break & therefore have to be modified. I'm not for tieing the hands of those who are architecting LS, but developers are going to find ways of doing things like this anyway, it makes more sense to have guidance on how to do it the "correct" way, rather than everyone coming up with their own "hacks".

Yann