Best Way to Order LightSwitch Project Objectives RRS feed

  • Question

  • Good Afternoon,

    I have a LightSwitch Silverlight/HTML app that I'm 80% complete with.  Things are going along good.  However, before going any further, I'm unsure about organizing the objectives to complete my project.  Here are the things I need to do:

    1.  Build App - I started the app using an Intrinsic database (as mentioned 80% complete)

    2. Merge and Import data into new app from 5 distinct data sources (Excel, Access, Proprietary dbs, etc.)

    3. Create reports via SSRS ( many will require table joins ).

    4. Create links to those reports inside the app.

    5. Incorporate third-party components into the app that require some data aggregation (table joins, stored procedures).

    Based on these objectives what is the best way to proceed? Can I do all this before deployment or will some it have to wait until after deployment.  If some have to wait, which ones and how do I make changes to the schema of the intrinsic database after deployment without breaking my app?



    Friday, August 2, 2013 6:13 PM


All replies

  • Not sure about the precise nature of your question.

    When it comes to deployment, I tend to deploy to a staging environment as often as possible (and especially after a major upgrade) and script also additional sql material. 

    paul van bladel

    Saturday, August 3, 2013 7:00 AM
  • Paul,

    Thank you for your reply.  So you don't wait until you're completely finished with your project to deploy.  So one could deploy and create reports then redeploy.

    What about table joins and stored procedure.  Once I have deployed to SQL Server with the first deployment, can I then write these outside of Lightswitch and then use them in Lightswitch?



    Saturday, August 3, 2013 11:39 AM
  • See for stored procedures a very recent post of Beth Massi:


    My advice on deployment to deploy frequently is not specific for stored procs, just in general. Eventually what matters is a deployed app, so if introducing a new feature in your app would cause deployment problems or simply wouldn't worked in the deployed version, you better know this as soon as possible.

    "Continous delivery" is just one of the modern practices in software development: http://en.wikipedia.org/wiki/Continuous_delivery

    paul van bladel

    Saturday, August 3, 2013 11:56 AM