Will general SL Client performance issues (already logged by others) be dealt with?

Will the SL CLient receive at least general maintenance and improvement over time?

Most of these questions address the SL client. Simple reason being that that's our only LightSwitch LOB option at present. Yes, we can achieve a lot of great things as things stand, however some of these issues present problems, both at design and runtime,
to say nothing of having to explain to a client why a particular something is done/presented the way it is.

I address these legitimate questions directly to the Team in the hope of some clarity. Some constructive response would be useful and very much appreciated.

Answers

There are a myriad of important concerns and perspectives raised on this thread. I’ll try my best to address Ian’s specific questions and share a bit of additional context to give you a sense of where we’re headed as a team.

Supporting a desktop range of devices (AKA, our client roadmap)

Our
first release of the HTML client was primarily focused on serving a set of devices and form factors that were out of reach due to limited support for Silverlight on mobile devices.We began with a focus on the phone form factor because it represented the largest addressable market for business app devices that was otherwise out of reach.
Support for larger tablet devices quickly followed based on requests in the forums and in customer discussions. UI for tablets and phones made it in for our first release in April 2013, and we’ve since been working to improve the user experience for the
largest screens and mouse and keyboard interactions.

There are a broad set of styling and shell changes and additional controls in development that will make the app more applicable to larger form factors—less padding, more tabular views of data, and so on.With the exception of new controls--which you’ll have to opt into using—many of the specific layout optimizations for larger form factors will be applied dynamically based on where the app is running-- similar to how our media queries for phones and
tablets work today.

While our HTML-based client’s support for the range of devices will improve with every iteration, we are not working on an HTML desktop-specific client release, per se—the distinction between mobile and traditional “desktop” scenarios is becoming increasingly
blurry; instead, we seek to provide an HTML-based end-user experience in the app that is effective for the breadth of devices and work styles found in the enterprise today. Similarly, we are not working to achieve functional parity with the current Silverlight
client in HTML. We do, however, aim to support a similar set of scenarios with user experiences and idioms that are more fitting for the breadth of enterprise devices and modern end-user expectations. The LightSwitch HTML client facilitates a highly productive
experience for solving the challenges of the modern business app
described by folks like Billy Hollis, whereas the Silverlight client was more oriented toward the traditional business app. (I’m certainly not saying the latter is more or less common today: the point is simply that the prevalence and acceptance of these
apps in the enterprise is diminishing.)

With all of this in mind, let me shed some light on the specific gaps we have heard from you that stand in the way of realizing the aforementioned vision.The gaps are listed in the order in which you can expect to see them filled.

Better use of additional screen real estate, described above

Better support for the keyboard.The app will still be touch-orient but keyboard accessibility and productivity needs to be improved.

Broader browser support: With our mobile focus, we focused on the specific browser versions on the most popular devices.Traditional desktops often entail a broader set of browser options and desktop users tend to be slower to adopt new browser versions.
We don’t aim to support every browser (read: things like IE 8 and lower) but we do want to address the known issues with some popular—if less recent—browsers found on the desktop.

More structured navigation in the app. Phone-oriented apps tend to rely on content-driven navigation exclusively, whereas apps running on larger form factors often benefit from a more structured navigation system that allows users to complete
multiple tasks in the app.As such, some sort of top-level navigation menu in the client is a gap we feel is important to fill.

Rapid/Bulk data creation. High end-user productivity is a salient characteristic of business apps: historically, great business apps have excelled at performing repetitive tasks quickly.This is a gap today, not just in LightSwitch but in the broader web app landscape.It’s a hard problem for us to solve, but our current thinking is that we can do far better than traditional solutions (e.g., large, editable data grids) by looking for new sources of the data that can easily be imported or referenced in the app, and
recognizing patterns in how users work—things like cloning records, tracking user activity, et al can help expedite tasks that have historically been completed by typing into a grid or page overflowing with controls.

The above items are only what’s on our immediate radar—it is our client roadmap for the coming Visual Studio updates, released quarterly—as we grow our current HTML client into what’s loosely referred to as the “desktop” space.We recognize that “desktop” has many connotations, so please do let us know the scenario gaps that exist today that need to be filled in order for the HTML client to be viable in this space.

What about Silverlight bugs and performance?

There are many facets of Silverlight’s future and LightSwitch is inherently entangled in each of them to varying degrees.Having personally reviewed the top rated issues reported and features requested for Silverlight client many times, I can attest that many of the most impactful bugs and—most notably—performance issues that plague our client are symptomatic of much larger
technology limitations.Specifically, the overwhelming majority of issues that impact folks are related to (1) performance –prohibitive memory pressure or CPU usage, which are often surfaced as hangs or crashes--, (2) the data grid, or (1
& 2) the performance of the Datagrid… We’ve invested considerable amounts of time in trying to address these issues, but rarely can the issues be solved without limiting the client’s addressable scenarios or impairing its performance further. For example,
conditional formatting in the grid is commonly requested; but adding conditional formatting can cripple the already sluggish grid performance in some very common cases. Likewise for autosizing.

There are all sorts of tips and tricks and dos and don’ts one can follow to create performant LOB Silverlight apps, but very few of those can be generalized enough to benefit LightSwitch. Speaking with full transparency, it is therefore unlikely that you
will see any considerably performance improvements in the SL client moving forward.We will continue to focus on improving client-sever bandwidth (e.g. using JSON-lite, better projection support, etc) but the performance and general issues with the Silverlight view layer are largely “as-is” at this point.

For features that are truly Silverlight client specific, my recommendation would be to consider banding together to create a community-driven version of the
Cosmopolitan theme and shell that includes the enhancements you feel are necessary.We deliberately structured the code for this shell and theme to facilitate the sort of enhancements that are often requested on the forums.The source is well-commented and pretty easy to follow if you’re familiar with Silverlight, and it encompasses all but the lowest level functionality in our client runtime—it’s possible to do quite a lot if you create a custom shell. Historically, creating
a shell and theme has been woefully difficult, but using the existing product source code is a much better starting point.

I realize that many of you will be underwhelmed by my suggestion to modify the source directly—I only mention it as a more viable option longer-term if the SL client meets your needs with the exception of a few features of the control set and/or shell. If
you are interested in going this route, please let us know if you have questions on how something works.You can contact me directly if you’re not
sure where to look, but the extensions forum is also a good place to start.

Will Silverlight receive general maintenance?

In a word, yes.We remain committed to testing and servicing the Silverlight client as needed.The Silverlight support roadmap is largely applicable to the LightSwitch Silverlight client.
Beyond time and resources, a key consideration for us in servicing the SL client is risk—meaning that some bug fixes introduce considerable risk into the product so there is always a judgment call to make (RE: Performance issues, as
mentioned above).Nonetheless, we review and consider every bug that comes in on a very regular basis.

A broader view of the LightSwitch future

Most of Ian’s questions centered on Silverlight, but I’d be remiss if I didn’t also shed some light on the other areas of investment we have on our horizon. This is a very terse summary, but I do want to mention the investments so you have a better sense
of what’s coming down the road for us:

-App lifecycle management. ALM has historically been a bumpy experience in LightSwitch—most notably in terms of team development, app versioning, publishing and deployment. You’ve likely seen some
recent improvements in this space and there is much more to be done in the near term.In the same way in which our data design experience expedites the process for creating an entity model, database, and view models on the client, we seek to optimize the experience for a team of developers who are building apps that run with well-known
deployment environments (Azure, Office 365, IIS, etc) such that many of the technology choices and configurations one must choose today are defaulted.

-Design-time performance. We know this is an issue, particularly for larger projects.

-Better integration with Visual Studio. There are a number of artificial limitations that have historically prevented LightSwitch projects from working well with other VS project types and tools—things like test projects,
database projects, the ASP.NET web stack and projects (WebAPI, MVC, etc), etc.The recently announced
Solution Explorer enhancements represent a large restructuring of the LightSwitch project system to facilitate this sort of integration, but again, it is just the first step. Expect more experiences like the recently announced
SQL Server Database Tools project in the future.

-Office 365 is our sweet spot. Office 365 is an ideal business app platform in nearly every respect: things like single-sign on and Active Directory integration just work; apps can be centrally discovered, installed, and
managed; the app runs where users are already spend their time—in Outlook, SharePoint, et al; the corporate app catalog is the ideal “store” for internal apps in bring-your-own-device environments; and so on.We recognize that the Office 365 app model is new and there is an adoption curve, but rest assured that the value propositions now and looking forward in building Office 365 business apps are huge, and our experiences for building business apps for Office
365 will get richer with every release.

I recognize that these additional investments do not address the specific concerns you’ve raised and face today; however, I do hope that the broader view will help contextualize how we think about the Silverlight client moving forward. There are certainly
gaps between the capabilities of our Silverlight and HTML clients today, but I think you’ll find that those gaps are closing quickly and the future for LightSwitch development is indeed bright. We are releasing updates on a very regular basis—roughly each
quarter—and the nature of building a browser-based client means we have been able to be much more responsive as requests and issues come in.

Thank you for the passion to improve the LightSwitch experience.
I know this process has been frustrating for some of you and I apologize for that.

My fear with the focus on Office365 & Sharepoint "apps" is that LOB desktop browser type "applications", as you and I know it, does not form part of the LS future. The fact that we never get any feedback or response from MS on this does not help.

I'm starting to get the idea that the word "desktop" is becoming like "Silverlight". Best not to mention. Maybe we should instead start talking about "large form factor" instead. If we are "stuck" with jQuery Mobile in the HTML client (and it certainly appears
to be the case) then at the very least we need an additional "large form factor" friendly theme imo. I think that is a prerequisite for a "large form factor" LOB applications in the HTML client.

I think we must accept that the days of the Silverlight client is behind us and we will at best get bug fixes in future. That is unless there is a major turnaround higher up in MS about Silverlight. It is simply not part of the corporate roadmap anymore.

My biggest bugbear in all of this is actually the fact that not one of my posts which address this subject have been replied to by a member of the Team; so far they have been ignored completely.

In the original post I specifically addressed the Team such that their can be no doubt. My questions are very clear and ask them to respond to fundamentals; they were certainly not rhetorical in nature although as time goes on it has become clear that that
is how they being treated by the powers that be!

I don't feel I have ever voiced my concerns or asked these questions in anything other than a civil and patient manner, despite the fact that on each occasion upon which I try to have this addressed, I feel in advance that I know I'm going to be disappointed.

Who knows what the reason for the lack of response to such fundamental questions for us as LOB developers is; corporate diktat perhaps. If so, I think the arrogance displayed in opting to treat their customers in this fashion is frankly breathtaking.

what i know is the whole team of SL was assigned a new project,so don't expect any new version, but maybe there is some updates or bugs fixed,no new features and that lead us to the fact that LightSwitch based on SL will not have any new features.

the revolution of HTML5+CSS3+JS library and the server side like asp.net will do anything SL can do and more.

the problem is with javascript,many years we write code using the powerful language like c# and now when we come to write simple JS program we get shocked.
but now things are changed we have new language the typescript,i did not try it yet but i see some demo and i think it will help us to overcome the problems with JS.

if LS html client give us some reasonable UI controls targeting desktop browser with the ability to write code using typescript for client that will be awesome.

i think full functional LOB html for mobile device is big joke ,it is ok for simple data entry that not require a lot of information and it is good for some simple queries.

my last word to LS team and i hope they listen to what i say here:

would you please just see what tools Oracle offer for creating LOB application, just see their tools and what they can do
now Oracle make some of their ADF free of charge and they call it "ADF Essentials" actually its amazing framework with rich UI controls.

I for one would be satisfied if MS would only provide bug fixes for the SL client. New features would be great, but we know that will not happen. Similarly, I see no evidence that any SL client bug fixes will be forthcoming. The bugs
have been logged and discussed for years with no action. I highly doubt that anything will be done at this late date, unless fixing a particular bug happens to be incidental to fixing something related to the html client.

I will give the html client a try if/when it officially supports the desktop (large form factor). At this time I do not wish to hack it or do a lot of custom work to make it (somewhat) viable. I have a wonderful SL client application that will
meet our needs for a long time. It would be nice to see just a little support for that product in the form of bug fixes just to bridge the gap until the html client is ready for prime time. If not, this will truly be a textbook example of how NOT
to bring a technology to market (oops sorry we invested a lot of time and effort, yours and ours, with an obsolete client technology -- we missed that email; but please try this other thing instead).

Glad you mentioned the free Oracle tools, I have that on my list to take a look at.

Bug, designer speed and runtime performance fixes would be wonderful and represents really all we are asking for on the SL Client front. I can't imagine there's anyone on here who seriously expected another version of SL to be released; I certainly never
have.

What we have here is another classic MS faux-pas (to put it politely). I know of very few other organisations that shoot themselves in both feet on such a regular basis. The problem is that these issues inevitably detract from the wonderful work they otherwise
do in many areas.

Forget html client as a proper de-facto Line-of-Business front end as it stands. Even MS have NOT marketed it as such. We were given a fantastic tool with the SL Client (and LightSwitch itself of course), almost manna from heaven
I would suggest; but now it is effectively dead ( wellbefore there is a
viable alternative front-end for LOB ) and its clear there is going to be no attempt to do anything about the niggles that hold back said SL Client.

With MS not even attempting to make us believe html5 is for LOB and never bothering even to
acknowledge our legitimate questions regarding road-maps etc, how much investment in time and money are developers and companies going to be willing to make?

Just lets see how long this topic goes without response from MS and/or the Team. Trust me, if weeks go by, it certainly won't be the first time.

And just how utterly disdainful would yet another non-response imply to the very community represented here. As I said at the top of the topic, the questions are very clear, unambiguous and eminently answerable.

What is also strange is that the HTML client is presented as a "complement"
to the Silverlight desktop client. So it is a complement to something that, as far as we can tell, is not going be supported beyond what we have today. This also acknowledges the obvious gap that is created by relying solely on the HTML
client.

The other, in my view, obvious one is the fact that in the SL client, our screen code, whether in C# or VB, enables us to perform all kinds of UI wizardry, event handling etc. The idea of reproducing all of that in horribly hacky JavaScript just pushes us
all away from RAD concepts as it applies to UI. Recall that the framework is supposed to take care of the data service plumbing etc, leaving us to concentrate on the Business and UI logic; things that our valuable time should be most spent upon.

Ok we can still write our BL in our favourite .NET language; great. But UI logic? Going backwards with JS.

Typescript is an acknowledgement that this conundrum is real; an attempt to provide a more intuitive and productive environment for Javascript code generation. To be fair, anything that will do that has to get a thumbs up.

Just think about all the intercept points we have available in the SL client in order for us to write useful code. Unless and until the HTML Client can emulate this sort of flexibility, the flexibility required for an
enterprise class (please note; those who would post examples of so-called LOB in html client screenshots; no disrespect intended I assure you) Line-of-Business application, then for
that scenario we are required to stick with the SL Client.

Just think about all the intercept points we have available in the SL client in order for us to write useful code. Unless and until the HTML Client can emulate this sort of flexibility, the flexibility required for an
enterprise class (please note; those who would post examples of so-called LOB in html client screenshots; no disrespect intended I assure you) Line-of-Business application, then for
that scenario we are required to stick with the SL Client.

In which case, at the very least, fix and maintain; please!

Ian Mac

I create enterprise class web pages every day. I mean I guess it is enterprise class because at my day job we have thousands of users running a nearly billion dollar organization :)

To me, a LOB application displays data and allow users to insert and update data.

Now, at my day job they will not use Silverlight. They use HTML. They manage parts of the organization using ASP.NET Web Forms.

So LightSwitch would be an improvement because it will perform the exact same functionality desktop or mobile vs. just desktop that the ASP.NE Web Forms currently does.

I appreciate that many organisations won't allow SilverLight deployments and that's a bugbear for many and can't be helped; witness duel-shoe bullet penetration scenario alluded to earlier. It's not clear from your response that you are creating those web-pages
using the html client however since you say LightSwitch 'would' be an improvement. If you are so doing; kudos!

Believe me Michael I would love to have the confidence in the html client (and ONLY using the html client) that would allow me to build out a full, for example, purchase, inventory management, sales and CRM application, or anything else that takes my customers'
fancy.

But I don't. And why? Simple. In amongst my various diatribes on this subject I keep coming back to the basic fact that MS itself does not pretend that it is targeting the html client for desktop LOB, neither do they pretend that it should be adopted for
that scenario! In which case they should fix and maintain the SL client so that those of us where the majority of our customers do NOT have such restrictive corporate policy can continue building-out with confidence until there is
a viable LOB alternative.

Seriously, if you can point me at such an example I'll be very happy to take a long hard look!

Its so easy (guilty myself) to get lost in all the detail of this argument (discussion :-)) ) to forget the fact that all we're asking is for just a little
respect in terms of having some clarity ( or even a response) from the LS Team regarding some very fundamental and legitimate questions.

We been waiting since 2 years to re-write our existing client server LOB App in LightSwitch, which was originaly developed in VB.net and SQL Server (involving Purchase, Inventory Management, Sales, Finance Accounting etc).

We thought that LightSwitch will improve with good support for Desktop Client (Silver-light, HTML 5, what ever) and
in built reporting solution.

Its utter waste of time from MS, with talk of Share Point Integration, OData Feeds, Mobile Apps, JQuery crap. Microsoft should understand that only 5% or less of real LOB App actually comes on Mobile devices, remaining 95% is on Desktop and other bigger
form factor devices with integrations to machines and instruments in the businesses (Weighscales, Scanners, Bar-code Readers Spectrometers and what not) . That's why it is called as LOB App.

I think original people who thought of LightSwitch as LOB app platform are no more on the team. They talked in real LOB App terms like Orders, Invoices etc in their original presentations. Now it is just HTML5, OData, Share Point, JQuery, NuGet, SignalR,
bla bla. LightSwitch is supposed to encapsulate this crap in the first place!!. And above all there is not end it. Every release there is new crap, with original LOB App platform thought process just fading away.

You make some fair observations regarding particularly the LOB app terms 'drift'; I hadn't really realised that, although I must say you sound even angrier than me!

Note as yet (ok I know it's only been a few days) that there has been zilch, zippo, nada, zero, nowt (a Northern England epithet for my international friends) response from those who truly matter in the context of the original post (no
offence intended to anyone contributing to this discussion; in fact do please keep your comments coming since that will keep this up top).

Team, were it not for the fact that these questions have been asked several times with no response; I would be happy to wait a little longer. Since that clearly isn't the case, please note my previous points re arrogance and disdain.

What about all those improvements that are coming in VS2013? They mention several and also:

"... Fixes for many issues you reported on the forums"

In particular, a single lsml file for each screen is terrific, I think, and allows they to open different designers for each screen, which can be opened simultaneously;
also, a single (file) view in VS is also an improvement.

I know it is almost sure there will be no improvements in "features" in LS SL client (like controls and so on); but what they mention about fixing bugs is important and maintenance
of SL client.

Well of course that's great! I've happily acknowledged in other topic(s) that, in particular, separation of lsml's is a Godsend plus the ability to have multiple designers open and only one 'view' of your solution; fantastic and great news!

Many software companies will itemise pending fixes in detail and communicate them to their development community; after all, if
they don't know what's in their latest maintenance build, then who the hell does! We are never told what is slated in the next release in terms of fixes to long-outstanding issues, so of course our assumption is that we are simply ignored!

There was ONE itemised LightSwitch fix in VS2012 Update 2, and that referred to Azure Publishing!

We've simply been asking for clarity and yes, respect in terms of having our legitimate questions responded to officially. No more, no less.

I still think that any impact to the SL client will simply be incidental to fixing the HTML client. I doubt that we will see changes or fixes to anything that is solely related to the SL client. I sincerely hope that I am wrong about that!

If community pressure, and competitive product pressure, could have forced a 180 degrees turn with the upcoming XBox One, surely we should be able to have some influence over the LS future?

However, unless MS as a whole has a change of heart with Silverlight, and I don't think that will happen, then it might be best to target our efforts at getting the HTHL client into shape for LOB development on large form factors.

Btw, Javascript is not that bad once you get the hang of it, but Typescript would be better for LOB development.

Oracle ADF certainly covers HTML, Desktop and Mobile. Their HTML pages are based on JSF (Java Server Faces) which is sort of like the Java version of ASPX pages. The ADF offering is certainly very comprehensive, can connect to any database that has a JDBC
connection and offers all the controls we could possibly require for web based HTML LOB applications. And it is very well documented (as already mentioned) and offers everything out of the box.

I worked in the J2EE space (now just called JEE) quite a bit around 2003 and I must say that I am very happy that I don't have to work with all those Session and Entity Beans and all the XML configuration that they required and the complexity they brought.
Things might have improved and become more simple now, but it was certainly not simple back then. The learning curve was enormous for new developers.

I hope LS does not force us to look at offerings like ADF but MS will do well to take into account what those other tools offer.

I have several applications running on clients, and I would not want to migrate to another tool, but MS can not even return nor our posts here in the forum, is a
complete disregard to the developers, the MS is able to evolve HTML and SL at the same time but does not and this is bad, because I like to use SL for now and have no need to use HTML.
You see yourself, how many years the SL exists today and has no integration with SSRS we are dependent on third-party components, and this is just one example. imagine if We did not have the components of the ComponentOne, DevExpress, etc ...
We would not have conditions to create a LOB application with quality. MS should review their priorities and improve what already exists and then invent other improvements, everybody would happy if the support SL was well documented and continued.

Actually, it is more of frustration than anger. LightSwitch could have been great platform for LOB Apps development, if MS were to support sound desktop based delivery with extensions on mobile and other devices. I think people like Beth Massi, who really
helped popularize LightSwitch even amongst professional developers, are made to talk about Share Point, Office etc

while Hessc and novascape answers was very clear i just want to summary:-

1.Oracle Application Express
this tools produce pure HTML,you need to know JavaScript for customization+PL/SQl(like T-SQL with sql server)
the downside of this tools it is just work with oracle database.

It's probably the rapid advancement in technology causing your desire for clarity. One must ask the question, that if technology is advancing so rapidly, will a sense of clarity around this technology (Lightswitch and Silverlight and HTML) really be that
fulfilling?

We live in a world that's rapidly evolving and I'm finding hard just to read all my emails at the moment. It's hard to keep abreast with all the new developments, and at the same time, provide a solution to a potential client, assuring them of on going
support for the foreseeable future.

This is where we need to be a little creative and not only be programmers, but also be life coaches for our clients. I would argue anyone who thinks they can identify what platform businesses will be using 10 years from now. MS probably realise this
as well. But one thing for sure, is that my Windows Vista desktop (don't judge) that's almost 10 years old can still run a Silverlight app just as well as my Windows 8 laptop.

Personally, I am loving Lightswitch and I look forward to any enhancements that MS deliver. I talk with people all the time that just want the app, because of how it can benefit them, and the technology is not a major factor, especially
when deploying in the cloud.

Most tradesman will tell you 'a good tradesman doesn't blame his tools'. Maybe this is how to approach Lightswitch? And I'm sure you would get a bunch of replies if you had a specific issue with your development in Lightswitch.

No Tim, it's really not; if you think about it, if MS doesn't have clarity of any sort, then we're all screwed!

'Most tradesman will tell you 'a good tradesman doesn't blame his tools'. Maybe this is how to approach LightSwitch....'

A really good tradesman will purchase the best tools; in which case he will have confidence in the manufacturer to provide timely support, resolve problems and treat him/her as if they were the only customer on Earth

'And I'm sure you would get a bunch of replies if you had a specific issue with your development in LightSwitch...'

How about 'specific issues' being raised (in detail) years ago and never dealt with?

I'm sure you didn't indent to come over as patronising but you do, a little; I'll forgive you though, because hey, that's the sort of chap I am ! :-)

One of the things I liked about the SL client was the RAD LOB capability, the one thing I disliked was that it was missing some very important features and as mentioned although we requested these features for almost 3 years, the requests have been mostly
ignored. This is likely due to the move away from SL, although we still lack those same features within the HTML client so not sure that argument holds up. I proposed a solution in a few of my own threads, in which I suggest that MS provide
the SL client source code, from which we could advance it as a community thus we could resolve the lack of features collaboratively. Unfortunately (very much like this thread) MS did not respond to any of my proposals.

But ... with the HTML client we actually have all the client side source code at our disposal and so I thought it best to roll up my sleeves and get down to the dissection of the core client side logic from that I would come up with a Desk Top
framework on my own.

I decided that the best way to do this was to put the HTML client into a documentation form that was easier to digest.

To that end I have created an Windows CHM generation tool that takes in JavaScript and spits out a CHM file which breaks each function scope down into help topics and further includes all variables and functions broken down into sub-help topics for
each function scope.

I then inject the actual JavaScript per each variable assignment or function logic into the body of the associated help topic and have resolved all links within that JavaScript snippet to link to other object members or function calls throughout
the entire CHM file.

There are around 87 dynamically generated types within this script that are broken into things such as services and functional areas to support the application client context, and I am further injecting these dynamic types into their own help topics
to help describe association and usage against the associated Variable Object Help topics.

This allows me to navigate backwards from the point of the Shell and look up the tree of creation.

I am providing a comments section per each help topic so that once I understand what a particular object, function or type is used for that I will inject these into the relating help topic. The comments will be maintained in a SL LS project, so that
when MS upgrades the script, that the comments can be reapplied and as well, that changes to that script can be easily captured and identified.

I am not 100% complete with the CHM generator but I can easily say that having this CHM document to navigate and search across the JavaScript has already provided me with a much better understanding and appreciation of
the HTML LS client from which I can easily say this is very complete as far as providing the core needs of forms over data.

Once I have a more solid understanding of the client side script I hope to build out a more complete LOB shell. There is of course a direct coupling to JQuery and JQuery Mobile that I hope to remove and replace with an extensions interface which will allow
me to integrate with many other 3rd party UI frameworks that provide a much richer story than does the current LS HTML Client.

I guess my closing thoughts are that based upon the lack of feedback, roadmap and support MS is providing to this post, I for one am not being held back. LS is a very cool product and we should be able to make it do whatever it is we wish. If we collaborated
together on this we'd likely end up with some very cool solutions using the HTML LS client.

For those that build LOB solutions over Oracle DBs this ADF approach appears (from these comments) to be the better approach, however most of my work is with MS SQL and so this isn't a viable option for me. I can't see me going back to building Oracle
databases (TOAD Anyone??) !

Further, if an ADF running LOB solution requires JAVA than I am most definitely
not interested.

I have to wonder, why did Oracle make ADF free? I suspect it was to boost its Oracle DB sales and not to provide a tool to build LOB to the masses.

Through the use of the Entity Framework, LS provides the ORM support for pretty much any Database that provides a ADO.Net provider, plus I can roll across SharePoint and ODATA services with ease.

For those that build LOB solutions over Oracle DBs this ADF approach appears (from these comments) to be the better approach, however most of my work is with MS SQL and so this isn't a viable option for me. I can't see me going back to building Oracle
databases (TOAD Anyone??) !

Further, if an ADF running LOB solution requires JAVA than I am most definitely
not interested.

I have to wonder, why did Oracle make ADF free? I suspect it was to boost its Oracle DB sales and not to provide a tool to build LOB to the masses.

Through the use of the Entity Framework, LS provides the ORM support for pretty much any Database that provides a ADO.Net provider, plus I can roll across SharePoint and ODATA services with ease.

My money is still with LS!

Cheers

Johnny Larue, http://www.softlandingcanada.com

Hi JLarue,

i want you to know the following:

1.Oracle ADF is not tied to any database it use jdbc driver to connect to database and that support by Sql Server too.

2. when i refer to Oracle ADF i want get LS Team attention to what LOB framework available.

believe me or not i still prefer to use asp.net mvc or asp.net web form instead of LS SL

There are a myriad of important concerns and perspectives raised on this thread. I’ll try my best to address Ian’s specific questions and share a bit of additional context to give you a sense of where we’re headed as a team.

Supporting a desktop range of devices (AKA, our client roadmap)

Our
first release of the HTML client was primarily focused on serving a set of devices and form factors that were out of reach due to limited support for Silverlight on mobile devices.We began with a focus on the phone form factor because it represented the largest addressable market for business app devices that was otherwise out of reach.
Support for larger tablet devices quickly followed based on requests in the forums and in customer discussions. UI for tablets and phones made it in for our first release in April 2013, and we’ve since been working to improve the user experience for the
largest screens and mouse and keyboard interactions.

There are a broad set of styling and shell changes and additional controls in development that will make the app more applicable to larger form factors—less padding, more tabular views of data, and so on.With the exception of new controls--which you’ll have to opt into using—many of the specific layout optimizations for larger form factors will be applied dynamically based on where the app is running-- similar to how our media queries for phones and
tablets work today.

While our HTML-based client’s support for the range of devices will improve with every iteration, we are not working on an HTML desktop-specific client release, per se—the distinction between mobile and traditional “desktop” scenarios is becoming increasingly
blurry; instead, we seek to provide an HTML-based end-user experience in the app that is effective for the breadth of devices and work styles found in the enterprise today. Similarly, we are not working to achieve functional parity with the current Silverlight
client in HTML. We do, however, aim to support a similar set of scenarios with user experiences and idioms that are more fitting for the breadth of enterprise devices and modern end-user expectations. The LightSwitch HTML client facilitates a highly productive
experience for solving the challenges of the modern business app
described by folks like Billy Hollis, whereas the Silverlight client was more oriented toward the traditional business app. (I’m certainly not saying the latter is more or less common today: the point is simply that the prevalence and acceptance of these
apps in the enterprise is diminishing.)

With all of this in mind, let me shed some light on the specific gaps we have heard from you that stand in the way of realizing the aforementioned vision.The gaps are listed in the order in which you can expect to see them filled.

Better use of additional screen real estate, described above

Better support for the keyboard.The app will still be touch-orient but keyboard accessibility and productivity needs to be improved.

Broader browser support: With our mobile focus, we focused on the specific browser versions on the most popular devices.Traditional desktops often entail a broader set of browser options and desktop users tend to be slower to adopt new browser versions.
We don’t aim to support every browser (read: things like IE 8 and lower) but we do want to address the known issues with some popular—if less recent—browsers found on the desktop.

More structured navigation in the app. Phone-oriented apps tend to rely on content-driven navigation exclusively, whereas apps running on larger form factors often benefit from a more structured navigation system that allows users to complete
multiple tasks in the app.As such, some sort of top-level navigation menu in the client is a gap we feel is important to fill.

Rapid/Bulk data creation. High end-user productivity is a salient characteristic of business apps: historically, great business apps have excelled at performing repetitive tasks quickly.This is a gap today, not just in LightSwitch but in the broader web app landscape.It’s a hard problem for us to solve, but our current thinking is that we can do far better than traditional solutions (e.g., large, editable data grids) by looking for new sources of the data that can easily be imported or referenced in the app, and
recognizing patterns in how users work—things like cloning records, tracking user activity, et al can help expedite tasks that have historically been completed by typing into a grid or page overflowing with controls.

The above items are only what’s on our immediate radar—it is our client roadmap for the coming Visual Studio updates, released quarterly—as we grow our current HTML client into what’s loosely referred to as the “desktop” space.We recognize that “desktop” has many connotations, so please do let us know the scenario gaps that exist today that need to be filled in order for the HTML client to be viable in this space.

What about Silverlight bugs and performance?

There are many facets of Silverlight’s future and LightSwitch is inherently entangled in each of them to varying degrees.Having personally reviewed the top rated issues reported and features requested for Silverlight client many times, I can attest that many of the most impactful bugs and—most notably—performance issues that plague our client are symptomatic of much larger
technology limitations.Specifically, the overwhelming majority of issues that impact folks are related to (1) performance –prohibitive memory pressure or CPU usage, which are often surfaced as hangs or crashes--, (2) the data grid, or (1
& 2) the performance of the Datagrid… We’ve invested considerable amounts of time in trying to address these issues, but rarely can the issues be solved without limiting the client’s addressable scenarios or impairing its performance further. For example,
conditional formatting in the grid is commonly requested; but adding conditional formatting can cripple the already sluggish grid performance in some very common cases. Likewise for autosizing.

There are all sorts of tips and tricks and dos and don’ts one can follow to create performant LOB Silverlight apps, but very few of those can be generalized enough to benefit LightSwitch. Speaking with full transparency, it is therefore unlikely that you
will see any considerably performance improvements in the SL client moving forward.We will continue to focus on improving client-sever bandwidth (e.g. using JSON-lite, better projection support, etc) but the performance and general issues with the Silverlight view layer are largely “as-is” at this point.

For features that are truly Silverlight client specific, my recommendation would be to consider banding together to create a community-driven version of the
Cosmopolitan theme and shell that includes the enhancements you feel are necessary.We deliberately structured the code for this shell and theme to facilitate the sort of enhancements that are often requested on the forums.The source is well-commented and pretty easy to follow if you’re familiar with Silverlight, and it encompasses all but the lowest level functionality in our client runtime—it’s possible to do quite a lot if you create a custom shell. Historically, creating
a shell and theme has been woefully difficult, but using the existing product source code is a much better starting point.

I realize that many of you will be underwhelmed by my suggestion to modify the source directly—I only mention it as a more viable option longer-term if the SL client meets your needs with the exception of a few features of the control set and/or shell. If
you are interested in going this route, please let us know if you have questions on how something works.You can contact me directly if you’re not
sure where to look, but the extensions forum is also a good place to start.

Will Silverlight receive general maintenance?

In a word, yes.We remain committed to testing and servicing the Silverlight client as needed.The Silverlight support roadmap is largely applicable to the LightSwitch Silverlight client.
Beyond time and resources, a key consideration for us in servicing the SL client is risk—meaning that some bug fixes introduce considerable risk into the product so there is always a judgment call to make (RE: Performance issues, as
mentioned above).Nonetheless, we review and consider every bug that comes in on a very regular basis.

A broader view of the LightSwitch future

Most of Ian’s questions centered on Silverlight, but I’d be remiss if I didn’t also shed some light on the other areas of investment we have on our horizon. This is a very terse summary, but I do want to mention the investments so you have a better sense
of what’s coming down the road for us:

-App lifecycle management. ALM has historically been a bumpy experience in LightSwitch—most notably in terms of team development, app versioning, publishing and deployment. You’ve likely seen some
recent improvements in this space and there is much more to be done in the near term.In the same way in which our data design experience expedites the process for creating an entity model, database, and view models on the client, we seek to optimize the experience for a team of developers who are building apps that run with well-known
deployment environments (Azure, Office 365, IIS, etc) such that many of the technology choices and configurations one must choose today are defaulted.

-Design-time performance. We know this is an issue, particularly for larger projects.

-Better integration with Visual Studio. There are a number of artificial limitations that have historically prevented LightSwitch projects from working well with other VS project types and tools—things like test projects,
database projects, the ASP.NET web stack and projects (WebAPI, MVC, etc), etc.The recently announced
Solution Explorer enhancements represent a large restructuring of the LightSwitch project system to facilitate this sort of integration, but again, it is just the first step. Expect more experiences like the recently announced
SQL Server Database Tools project in the future.

-Office 365 is our sweet spot. Office 365 is an ideal business app platform in nearly every respect: things like single-sign on and Active Directory integration just work; apps can be centrally discovered, installed, and
managed; the app runs where users are already spend their time—in Outlook, SharePoint, et al; the corporate app catalog is the ideal “store” for internal apps in bring-your-own-device environments; and so on.We recognize that the Office 365 app model is new and there is an adoption curve, but rest assured that the value propositions now and looking forward in building Office 365 business apps are huge, and our experiences for building business apps for Office
365 will get richer with every release.

I recognize that these additional investments do not address the specific concerns you’ve raised and face today; however, I do hope that the broader view will help contextualize how we think about the Silverlight client moving forward. There are certainly
gaps between the capabilities of our Silverlight and HTML clients today, but I think you’ll find that those gaps are closing quickly and the future for LightSwitch development is indeed bright. We are releasing updates on a very regular basis—roughly each
quarter—and the nature of building a browser-based client means we have been able to be much more responsive as requests and issues come in.

Thank you for the passion to improve the LightSwitch experience.
I know this process has been frustrating for some of you and I apologize for that.

@Marden LR: The answer to your question is covered by Joe above in the following quote (basically, *none* of those will happen in the SL client and will have to be done as a community project using the recently released Cosmopolitan Theme and Shell):

"Speaking with full transparency, it is therefore unlikely that you will see any considerably performance
improvements in the SL client moving forward.We
will continue to focus on improving client-sever bandwidth (e.g. using JSON-lite, better projection support, etc) but the performance and general issues with the Silverlight view layer are largely “as-is” at this point. "

"When" is the big question for me regarding the HTML Client for desktop LOB-type use. It's the difference between trying to make do with the (performance) limitations of the Silverlight Client on a large app, or starting to move all my work over to
the HTML Client. I know I'll do the latter eventually, but it would be helpful to know if we're going to have a desktop-type theme (with lists/grids, multiple-tabs, navigation, etc.) in 2 months or 6 months (or god-forbid, even longer).

I'd even be willing to write the shell and controls myself if the kind of extensibility of the SL Client was available (and documented), but this doesn't seem to be the case.

Many thanks for getting back to us. You won't be surprised if I suggest that this has been a very long wait (not referring to just this topic) and has taken a great deal of 'user-noise' to get here. While I completely accept that you guys would be unable
to do your 'real' work should you spend much time in the forums, these fundamental questions have been hanging in the air for months now.

You are absolutely on the money regarding the passion; in many ways we love the product and what it's possible to achieve with it. It's just a great shame that our appreciation of the plethora of goodness often gets drowned out by the noise surrounding these
issues; the frustration has been the lack of clear direction in terms of where LightSwitch goes from here in terms of performant Line-of-Business application development.

Unless I've misread, we can sum things up to the following:

If we want to build medium-to-large sized SL based LS Line-of-Business applications, we're stuck with acknowledged design and run-time performance issues which are very unlikely to be addressed, along with requested features only gaining traction so long
as they also fit within the intended roadmap for the HTML client. Seriously Joe, have you sat twiddling your thumbs while the modifying of a single property on a screen churns away at you for 2 minutes? Are you really going to tell us that this cannot be improved?

If we want to build end-to-end Line-of-Business applications (as opposed to Business 'apps', unless those two phrases are interchangeable in current MS parlance, perhaps you could kindly confirm this) with the HTML client, we can't as things stand.

Assuming the two phrases are not interchangeable but describe two altogether separate scenarios, then I'd be grateful for your input regarding which MS tools we
should be using now to develop, say, an end-to-end Purchase/Inventory Control/Sales/Billing and Accounting solution in the RAD space ?

@Elyl: We are actively working on the larger form factor gaps I mention above. Moving forward, we are decreasingly reliant on "big" Visual Studio releases, and instead work on a top-down burndown and ship completed features in the subsequent Visual
Studio update. While we are not a year out on completing this work, I can't say with certainty that it will be stable enough to release in the next update. The nature of this work is such that some of the changes can be released earlier than others. UI-level
changes, for example, are lower risk and you're likely to see them in the near future, whereas changes to the data interaction/workspace are often more involved.

@Ian

1. Design-time performance of the SL client is still very much a priority, and we continue to make inroads here. F5 time and overall size of the client package has been a recent area of focus, as these have been particularly problematic for larger
apps. Screen and entity designer performance has also gotten better with the move to separate LSML files, and we have another round of refinements to further improve performance of model (LSML) changes. In terms of runtime performance, we would be more
than happy to look at the specific scenarios where you're experiencing these delays and provide some insight. While we do get perf bugs, very few of them repro without the full extent of the deployed enviornment available. And in most cases, there
are workarounds we can suggest for specific scenarios, as some UI designs are inherently latent. I'm by no means asserting that there are no performance bugs in the LightSwitch client or core Silverlight runtime; I am only suggesting that there may be
some do's and don'ts from a perf perspective that particular scenario can benefit from, and we'd be more than willing to help work with you on that. Let me know if this is something that'd be useful to you and we can arrange it via email.

2 & 3. In terms of the right tool for RAD applications, we certainly have more than a few "very large" companies who are very successful building the types of apps you describe with the LightSwitch SL client. These apps have hundreds of screens
and entities, and it's experiences they've shared with us that have motivated many of the changes we've made in VS 2013--better team development, ability to put LS assets in folders, etc. That said, no single tool is right for every scenario and I am
not sure there's an answer to your question that one can offer without a deeper understanding of the context. For example, some of the examples you cite closely overlap with things that Microsoft Dynamics (ERP, CRM, etc) cover very well.

In reference of the distinction between "apps" and "applications", the broader notion of an enterprise application is very much changing. This is not a Microsoft or personal assertion: we're seeing companies who have historically built very large,
do-it-all applications look to a sophisticated, centralized service layer that is consumed by many smaller "apps". It's a model that is much easier to manage from a cost and delivery/deployment perspective, and end-user acceptance of the "app" concept
is widespread. Obviously, not all businesses are there yet and there are some key business functions that will still be served by a more full-featured application, but fewer and fewer of those do-it-all apps are built from the ground up with RAD tools;
they are either bought from a SaaS provider and customized with "apps" or--if the organization is large enough--the service is built-in house. LightSwitch's sweet spot will always be building "apps" that integrate these services to perform new business
functions or satisfy unique business requirements. Other RAD tools in the market who have significant share are taking a very similar approach. This is a much larger topic--and a very healthy discussion for us to have--but probably not well-suited to
this forum thread. I only mention the additional perspective to give contextualize our focus on "apps" with deep integration with services in the enterprise.

In order to successfully take care of some of the SL concerns as a community it would require us to have more than just the source code for the Shell. In particular, the runtime memory and performance concerns are not going to be addressed at
a Shell level, these require access to the client assembly source code.

So once again I will propose (3rd or 4th time) that MS kindly release the source code for the SL client so that we as a community can resolve our own issues. I fail to understand why you would not given that you do not intend to
evolve this code, and given that the HTML exposes the same logic within the msls.js script?

I really can't see how modifying the shell extension is for example going to resolve Data Grid memory issues but I can see how having access to the application context source will allow us to do a lot of what we have been asking for over the past 3
years.

So if you can at least reply and let us know whether or not MS would release the SL client source code for LS and if not at least let us know why not.

There are a broad set of styling and shell changes and additional controls in development that will make the app more applicable to larger form factors—less padding, more tabular views of data, and so on.With the exception of new controls--which you’ll have to opt into using—many of the specific layout optimizations for larger form factors will be applied dynamically based on where the app is running-- similar to how our media queries for
phones and tablets work today.

I feel it would be more prudent if you were to provide extension capabilities within the msls script that will provide a clear decoupling from the shell layout, navigation and screen encapsulation rather then provide us with a single fit, based
upon opinion of where the LOB application is going.

As you know, there are a ton of very cool JS frameworks that are built on the concept of providing control capabilities for today that will be made available in subsequent releases of JS language, AngularJS, Sencha.

I appreciate that MS is concerned about building highly performing controls which will bind nicely with the LS client context but that is the very thing that will delay us from being able to fully embrace the HTML client.

I would suggest that you first provide us with clear (documented) points of extensibility to allow us to integrate with any 3rd party UI framework much as you did with the SL client.

It seems to me that most of the underlying framework capabilities already exist within your script, but since its a all-or-nothing opt-in approach, it does not leave us with clean options for integration to other frameworks.

I suggest that the first step towards the adoption and success of the HTML LS client would be to provide a highly extensible client context that manages the life-cycle of the forms-over-data and let us leverage the controls
and UX capabilities provided to us by other 3rd party frameworks. It would appear that you have most of this complete with the exception of the points of extensibility.

Then second to providing a highly extensible client context would be to develop out new controls.

In reference to the open source-ifying the SL client, I'm afraid this is more of a technically challenging than logistic or time-constrained. In practice software needs to be built with the open source model in mind from the onset, and the core runtime and
design time components of the SL client were not. The specific issue is that if the client and its accompanying design-time components were made available as source, the runtime and design-time cannot be easily re-boostrapped into the app and Visual
Studio--that's why I was suggesting that a more tenable approach would be to use the source that relies on well-supported extensibility points. It's true that you couldn't fix the grid performance issues, for example, with a shell (some of the above feature
requests could, however, be addressed with a theme that retemplates the grid though); but the source for the grid control itself probably could. In short, releasing the source is only one piece of the puzzle and I think in practice it wouldn't achieve the
result you're requesting. But if having the source for all of the extensible aspects of the runtime or design-time would be helpful, that's a much more tractable problem for us to think about.

In terms of HTML client extensibility, the team's thinking is in alignment with yours. When we began building the HTML client many of these frameworks didn't exist or weren't mature enough to rely on; but the landscape has changed considerably
and we want to facilitate others using these well-known frameworks "as-is" with LightSwitch. It's something we're still working through and there are some compatibility concerns to address, but I think you're perspective is right on.

I understand that the LS Team have been working with ComponentOne (C1) with their Wijmo components. What C1 has done to integrate Wijmo with LightSwitch will allow me to build some nice looking HTML screens to compliment our SL Client Screens.

BTW: I have never had any Data Grid memory issues or performance issues with LS with the SL client. I just released our apps into production with VS 2012 Upd 3 and users are reporting that the apps are running faster now. However,
I have been very diligent in the database design and indexing for our LS apps. I am also careful in how I build apps with LS so that they perform well.

Most of my users don't know that our LS apps are web apps. They think they are desktop apps since I publish them with the OOB option.

Indeed, the ComponentOne team has developed a great set of controls that fills many of the gaps outlined above for both Silverlight and HTML. Their HTML suite has recently become available, and it's definitely worth a close look: http://www.componentone.com/SuperProducts/LightSwitchHTML/.
Longer term, our partners will always serve an important need in our story--particularly for controls.

I am glad that you have had success with LightSwitch in enterprise production environments--your experiences are representative of the overwhelming majority of folks we talk with, but it's always refreshing to hear :).

Thanks for the response. We just deployed a mid-to-large SL client app and we are happy with it. The performance is a little slower than I would like, but by using all the various optimization tweaks we managed to get acceptable performance
out of it. I am disappointed that the SL client will not evolve in the way I had hoped when I started the project, but I appreciate you providing insight on where things are heading.

Thanks for your detailed and insightful responses to this thread, it is much appreciated as it provides (especially) small business owners like myself with a technology roadmap that we can work and plan to. When we don't know what is coming or where the
product is heading, a seemingly small technology decision or assumption might mean the difference between success and failure for us.

I am encouraged by your mentioned work to improve suitability for large form factors. This was probably my main "criticism" of the HTML client to date. Like many others, I feel passionate about LS, but I also strive for UI perfection, trying to get the UI
looking as perfect as I can within budget and skill constraints. I've always maintained that the user assumes everything underneath is working, so they judge the application by what they see. So we need to try and get that as good as possible, and preferably
out of the box where possible.

I was involved in a large scale multi-tenanted LS Silverlight (still running on LS2011) application used around Australia. LS was the perfect choice for that application and we get tremendous feedback on how well it works and even manage to get customers
away from a competitive product. It never ceases to amaze me how easy it is to maintain and enhance the application - this is one of strongest features of LS! It is only once you try and develop software using any of the other popular frameworks that you realize
how good LS is at this.

The new team development support with multiple separate model files is a great enhancement. Kudos to the team for that one!

Can I make another couple of suggestions:

1/ Modular development in LS is something that has been discussed and requested by the community for a long time. I think the ability to have multiple HTML clients (as separate modules) within one LS project, all sharing the same data source and the same
login and with the ability to deploy as one overall app will be huge! I'm currently working on an app with 3 separate LS projects (as separate modules where each contains a separate HTML client) and being able to add all three HTML clients into the same LS
project will be nice. I would be keen to hear whether this is on the radar?

2/ The benefit of this thread to the community is huge. May I suggest that the LS team creates something along the lines of a quarterly online Q&A session about LS where the community can discuss these kinds of issues with the team directly? Regular
two way communication between the community and the LS team about where LS is headed can only be a good thing for all parties?

Thanks again for taking time to respond in such detail. We look forward to the next delivery!

So I finally took the plunge and did a right click, add client (HTML), to a copy of one of my large SL client apps. I have to say I was very impressed with many aspects of the HTML client. I am starting to see the potential. When using
it with my already robust middle tier developed for the SL client, it was much better than some of the small, two to three table, test apps I had tried previously. I could really see how it works. I agree that once a large form factor theme, or
even an "all" form factor theme emerges, it will be a worthwhile investment of time to build it out. I have been a very big advocate for the SL client so I believe it is only fair to provide this feedback for the HTML client. I will be following
its progression with great interest, and in the meantime, working on my sub-optimal java script skills.

Many thanks for such detailed information, it makes such a difference to have some clarity and the roadmap you outline certainly looks intriguing and allows for more informed dialogue when talking with clients.

Re SL performance (particularly design-time): we converted one of our larger apps to VS2013 format and so far have not come across the tremendously irritating screen/query designer slowdowns once, so great kudos for the multi lsmls enhancement
plus the ability for multiple designers; this is an incredible productivity boost!

Now all that has to happen is to get some 3rd party extension providers (DevXpress XtraReports, ComponentOne) to update their packages for VS2013; another story no doubt!

"But if having the source for all of the extensible aspects of the runtime or design-time would be helpful, that's a
much more tractable problem for us to think about."

Can you provide some feedback as to whether you could help us with the issue of large SL LS projects that have bloated XAP files due to having a ton of screen and entities defined
by providing us with a runtime library that would allow us to dynamically load additional components from other LS SL client XAP files using
this technique as described
here.

It seems to me that with the upcoming VS 2013 LS preview, LSML fragmentation of screen and entity definition that that this approach makes even more sense.

To do this, it would be extremely helpful if we were able to build multiple SL clients within the same LS project such that each client
shares the same backing LS ODATA service. Providing this capability may allow us to establish one of the LS projects LS
clients as the core program and configure the remaining LS client projects as modules of that core program which are dynamically downloaded and composed into the core loader via way of MEF through user actions within the Shell.

Having studied the SL Client assemblies, this looks very doable provided once we loaded these client modules, we were able to invoke
ModuleLoader.LoadModuleFragments on the loaded module client. It appears that the
LoadModuleFragments method
is currently only called at application initialization and in this proposed approach we would be required to call this for each
LS module shortly after we downloaded them. Due to the fact that this is a signed and sealed MS client assembly we are
currently not able to experiment with this concept. It does appear from a study of the LS runtime assemblies that this approach is doable but that it would require MS to provide us with a wrapper to allow us to invoke the
LoadModuleFragmentsmethod
on the LS module we download dynamically.

If my assumptions are correct, all we would need is for MS to provide us with a simple assembly that wraps and exposes the
LoadModuleFragments
method as a public method so that we can invoke this call after we load these LS modules into the client so as to load
the additional Navigation Groups, Screens and related LSML fragments as a user requests them.

As I see it, this simple wrapper would not require any changes to the VS design-time thus not a very big ask. There is of course the need to allow for multiple SL clients but
this can by manually configured to include multiple clients, so that at least we could experiment with the concept.

Of course there is always the unknown, so could you please provide a quick response as whether this idea has any legs or not.

@Xander /1: We've heard this feedback from a lot of folks and we're close to enabling it in many respects but not quite there yet. It's something we're working towards with every update. (We actually supported something similar to this during our first
HTML preview but scaled it back on account of some technical challenges.)

@ Xander /2: This is a great suggestion! We'll sort out the logistics shortly and post a sticky thread on the forums. In talking to a few other teams that do this, a model that seems to work well is to give folks the opportunity to submit questions
in advance so we can do our homework and get you the right information for the live discussion. Of course folks can ask questions directly, too. We can try it in August and--if there's sufficient interest--it can become something more steady.
Sound good?

@ Johnny: There's a bit more to composing and interacting with the LightSwitch model than meets they eye, I'm afraid. But I very much understand the spirit of the request and the level of support you're asking for, so let me dig in with extensibility
gurus on the team to see if there's something we can do here.

Thanks all. We're looking forward to continuing this conversation live next month.

Thanks so very much for getting back. I figured that there was more to composing the LS model than what I proposed.

I really look forward to hearing back from your extensibility gurus on any ideas that they may have.

I have a couple of very large applications in mind that would most definitely benefit from this capability, as well, I have had many larger companies contact me requiring a similar need.

If you require any support to build and test related POC please do not hesitate to reach out to me directly via email : john at softlandingcanada dot com, I would gladly provide any assistance as required.

Re suggestion 2 and the Teams' immediate and most welcome willingness to action it: please let me know what your trick is; it's taken months of berating to get this far, then your 5-line suggestion gets an immediate thumbs-up; wish I had known in the
first place that that's all we had to do! :-)))

Seriously, very well done and many thanks; things should now move in the right direction judging by Joe's posts; It'll be great to get direct feedback with the Team at last!