none
VS2013 (SL Client) screen designer performance issues

    Question

  • Hi all,

    I converted an LS (SL client) solution from VS2012 to VS2013RC. Prior to doing so I had to uninstall ComponentOne OLAP and DevXpress XtraReports extensions as the conversion failed otherwise. In the converted version of the project I re-incorporated latest versions of all extensions and rebuilt successfully.

    Unfortunately when I open ANY screen.lsml in the designer, the first change I make to it takes up to 4 minutes to complete and during this time VS2013 is totally unresponsive. If I then open another screen.lsml and make a change there (even a DisplayName change), the process repeats itself.

    Obviously in my case this is totally unusable.

    I have tried many things, to no avail whatsoever!

    I had thought that maybe there was something specific in my (unconverted) project that didn't 'translate' too well during the conversion, so I had the idea that maybe I could re-create a VS2013 version from scratch by creating a new LS solution, adding my extensions and packages and then copying my data model in (my model has many aliases of the underlying datasource fields and I didn't want to have to recreate this by attaching then painstakingly through the DataSource dialog then having to rename everything). I figured this way I might be able to get a 'clean' project which might remove the issue of the designer performance.

    Clearly this does not work either. If I just copy what is in Server.DataSources from my (converted) project to my new (scratch-built) project, the objects in the Server.DataSources folder (in scratch project solution explorer) do not resemble what they should; objects that are queries are not linked 'under' their respective tables but are entirely separate from anything else, for example. Also the icons for these objects are incorrect and tend to show as text files.

    Needless to say a build is impossible under these circumstances!

    Obviously I'm missing a few tricks or alternatively it's just not possible to re-create a project this way; I'd be most grateful for some assistance, either with possible causes and fix(es) for the designer issues or my method of attempting at a solution, or both!

    Many Thanks


    Ian Mac


    Edit: On attempting to change screen property value i.e. DisplayName of a control, CPU rises to 54% and floats around that figure for the duration; CPU fan kicks in. There is 0% disk activity for the duration. Have disabled anti-virus/firewall etc; all remains as above however
    • Edited by Ian Mac Wednesday, September 18, 2013 2:23 PM Additional info
    Wednesday, September 18, 2013 10:38 AM

Answers

  • Hi everyone,

    Just wanted to let you know that we also got this fix into the Visual Studio Update 4 bits! Those bits have not released yet, but will soon. So if you are experiencing this design time performance issue (where using a custom display name in the entity designer causes perf problems when opening screens, like in localization scenarios) then you will need to install either Visual Studio 2012 Update 4 RTM or Visual Studio 2013 RTM. These will both release soon.

    Thanks for helping us track down this tricky perf bug.

    Cheers,
    -Beth


    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Monday, October 14, 2013 11:20 PM
  • Sorry for forgetting to follow up here. Yes this has been fixed for RTM. Thank you all for helping us track this down!


    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Wednesday, October 09, 2013 4:31 PM
  • Hi Ian,

    Sorry if I'm not being clear.

    1 - The perf bug AND the extension upgrade issues you reported on this thread ARE fixed and checked into main VS2013 RTM

    2- We are not able to promise a fix for the perf bug in VS2012 at this time. There are a lot of moving pieces to the Update 4 release process and although we are trying to get this fix approved, I can't promise we will.

    Your solution will be to download VS2013 RTM on October 18th upgrade your projects then.

    Thanks,

    -Beth


    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Thursday, October 10, 2013 9:05 PM

All replies

  • I can second this. Screen designer hangs on complex screens when doing the first change. Thereafter it is fast.

    As for your 2nd issue.

    Have you changed the build action of the .lsml to LightSwitchModel? After that you can edit it and when you did the first change, you'll get icons back.

    Wednesday, September 18, 2013 12:33 PM
  • Hi,

    Yes I had already reset the build action on the lsml files. It hadn't changed the icon or make any other difference unfortunately!


    Ian Mac

    Wednesday, September 18, 2013 12:46 PM
  • it changed it here only when doing some modification. Does the designer open?
    Wednesday, September 18, 2013 3:27 PM
  • No, says no designer support for this file!


    Ian Mac

    Wednesday, September 18, 2013 4:00 PM
  • I will add myself to the list of users experiencing this. The screen design performance in VS2013 RC for me is the same as VS2012 with latest update. Always first update like delete a column, 2 - 5 minutes, delete 2nd column, 1 second. Complex screens, 100+ nodes, reproducible all the time.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Wednesday, September 18, 2013 6:58 PM
  • No, says no designer support for this file!


    Ian Mac


    Oh I see. Its not working on tables as suggested. Guess I tried some screens then. You can create an empty table (query) with the same name and then replace it with the old file.
    Thursday, September 19, 2013 7:54 AM
  • Dave,

    Yes confirmed same issue in VS2012 latest update, although of course that is with a monolithic client.lsml

    It's therefore very frustrating that, given the new, single .isml per screen environment, this issue is apparent. To be honest, at the moment this pretty much takes away from what was on the surface a very promising change to the development scenario.

    The problem (perceived or otherwise), is that we've as yet had no response from the Team on this or pretty much anything to do with SL design-time performance, as witnessed in various other threads. On the other hand yesterday I posted an issue regarding frozen builds (non-specific client) and have already got two members of the Team working on it!

    I DO hope someone takes up the mantle on this one since actually it's not about overall design-time performance in the SL client, just this one very frustrating issue, given the eagerly anticipated changes which came about with VS2013 it's a bit of a come-down. Especially since all we've had so far is lots of 'me-too' responses!

    (Small) consolation there of course is that it means I'm not the only one!


    Ian Mac

    Thursday, September 19, 2013 1:15 PM
  • This does help by reducing the items in a screen but it does not solve the issue :)

    Part #1

    http://xpert360.wordpress.com/2013/09/19/something-you-should-know-about-lightswitch-screens-part-1/

    Part #2

    http://xpert360.wordpress.com/2013/09/19/something-you-should-know-about-lightswitch-screens-part-2/

    There is more to come!

    If you have ANY and I mean ANY LightSwitch Rich Client / Silverlight application then these articles will apply to you.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Thursday, September 19, 2013 9:20 PM
  • Copying LSML files from one project to another isn't a scenario we support.

    That said, be sure you're copying "Server\Properties\DataSources\YourDataSource.lsml" as well as the "Server\DataSources\YourDataSource" folder.  You'll also need to copy the appropriate definitions from the client's "Properties\proxies.lsml", and you may need to update the EntityContainerGroup items in both Client.lsml and Server.lsml.

    As for the screen designer performance issue you're experiencing, it would be a big help if you could provide a sample project that demonstrates the issue.

    Friday, September 20, 2013 3:01 AM
  • Hi Andrew,

    Would the best way to do this be for me to put it under my cloud TFS account and allow you access?


    Ian Mac

    Saturday, September 21, 2013 9:51 AM
  • This problem is not as straightforward to reproduce as it looks. Nevertheless we have concrete steps to reproduce a problem exhibiting these symptoms from machine to machine.

    The user base has lots of patience, the LightSwitch team too but we are left wondering 'is this taken seriously?' when posts like this just got ignored:

    http://social.msdn.microsoft.com/Forums/vstudio/en-US/9edc9ba0-9c04-483f-96f5-3ad0571dc857/big-design-time-performance-regression-in-lightswitch-v3

    Ryan Lin was onto this problem in April 2013. The LightSwitch team should embrace the user base, there is a lot of help out here! Major problem, ignored for 6 months since the user base diagnosed the problem. Does not make good reading does it? Is it going to be another 6 months?

    Finally and hopefully this can be sorted, so try these steps and good luck!

    For information: PC i7 quad-core Windows 7, VS20120, VS2012 Update3 and VS2013 RC

    Step #1

    You may as well start with a ready made data source: Data adapter for Dynamics CRM

    Xpert360 Lightning adapter Dynamics CRM for LightSwitch

    New version works with VS2012/2013, real-world size schema, lots of display names and descriptions.

    Go download and install it. No need for a Dynamics CRM instance, you will only use it in design :)

    Step #2

    Proof that it did work once! Go for a LightSwitch V2 flavour of project. Feel free to save the project at each step.

    A: Create a new LightSwitch desktop project in VS2012

    B: Go to project extensions and enable the Dynamics CRM extension

    C: Add new Data Source, WCF RIA service, select Dynamics CRM

    D: Unselect the entities node - go select the 'Accounts' and 'Contacts' entities. continue...

    E: Add new List details screen, select 'Contacts' data, go... this is now the base project and screen to work with!

    G: Click on the first property 'FullName' (or any) and press delete. It works in 1 second.

    Step #3

    A: You need to recreate the project from Step #2 in VS2012 V3 and VS2013 V4 project flavors.

    B: VS2012 V3 -> Right-click in solution explorer and upgrade the V2 project.

    C: Open the ContactsListDetails screen.

    D: Click on the first Contact property 'FullName' (or any) in the details and press delete. It takes 3 minutes!

    Step #4

    ... recreate the test project in VS2013 RC

    D: Click on the first Contact property 'FullName' (or any) in the details and press delete. It takes 3 minutes!

    So please follow the above steps and get back to us.

    Many thanks

    Dave


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.



    Saturday, September 21, 2013 11:55 AM
  • Hi Dave,

    Another sad one like me working on Saturday! :-)

    I saw that post by Ryan ages ago but couldn't for the life of me figure out exactly what he was doing; where the code goes, how it's integrated etc and nothing else was forthcoming!

    Well done for posting exactly how to reproduce; I DO hope we can get an answer to this very soon, it's driving me, you (and others I suspect) nuts!


    Ian Mac

    Saturday, September 21, 2013 12:52 PM
  • The amount of time and effort spent on this, rather think we should send an invoice to Microsoft for doing their job LOL :)

    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Saturday, September 21, 2013 12:57 PM
  • For me it looks like the people at MS has no experiences of building real LOB's because they gave us samples which are not represent real scenarios...

    for the SL client I think they have the problem that there is a bad design and they cannot make it better because of this...

    it is a shame that in 2013 we have development environments from MS which are slow, sluggish and not RAD - they killed VB6 and build NET and now it is not clear which are the technology for the next year for building intranet LOB (WPF & SL is dead, WinForms is old, HTML5 & Javascript = Lightswitch is not usefull for "real" LOB's)

    why always build everything from new and not extend and improve existing technologies - MS begins always at Version 1 (or Beta) and forces us developers to invest a lot of money and time to learn new technologies and then cut this - as the SL Lightswitch client...

    I am very disappointed about this

    Robert

    Saturday, September 21, 2013 1:23 PM
  • Yeah I wish!

    Ian Mac

    Saturday, September 21, 2013 3:16 PM
  • You know Robert, what you describe has bugged me for a long, long time. I had been trying to get definitive responses from the team for months about these issues and it got to the point where my posts and others had been ignored for so long that sheer frustration set in. I started a new thread and just got to the point with the Team, asking direct, simple questions. Even then is was quite some time before the Team finally responded. Others got involved (which was the idea) and to cut a long story short, it ultimately resulted in the setting up of the recent 'Town Hall' online meeting. This didn't really address the points I'm making below but to be fair, it was a good start with limited time and shows the Team have been willing to open a new (and very much appreciated) channel of communication.

    I am particularly concerned about the whole HTML5 'LOB' (or not) scenario. Granted we can build great LOB in SL client, but as you say it does seem as if anything we put across as issues arising within this environment gets (to put it mildly) left on the back-burner; certainly these issues do not get the priority they deserve, considering that we ALL know that we cannot build full-on LOBs with the HTML Client in the 'traditional' sense. And yet SL is guaranteed to be supported until 2021!!

    As a simple example, what use an SPA when a user might be on the 'phone to a client and needing to confirm or talk about several things at once? How easy is it to look at all the details of an order, the Invoices against it and payment history against those Invoices in one scan? You wouldn't (and couldn't) do that on a mobile anyway! And that's the point. The HTML Client is aimed at devices, and, to quote someone far better placed than I but whose name I unfortunately forget, 'no real work gets done on devices'.

    So my contention is the same as yours and unless I'm misinterpreting you, it goes basically like this: We have an existing LOB framework that is neglected, third party support for which is diminishing rapidly (check out how many SL extensions have been updated, let alone released, lately), on top of which you get the sense from all the Team activity that we are being directed that the HTML5 client is the way to go for everything, but this clearly isn't the case (at least, not yet).

    Obviously I'm talking about systems that will run in desktop screen size. What I would really like to see is a Team-designed, full-on demo LOB application written in the HTML Client as an example and guidance, but most of all encouragement to the community. I mean I really want to be able to use this with confidence, but I cannot take seriously the plethora of 'movie database' et al SPA 'examples'. None of these represent the real-world systems most of us are involved with in the slightest and, since this is a relatively fledgling technology, an example such as that mentioned above would be a great help to most developers, who, let's face it, spend so much time building for their clients that getting a grip on the whole HTML client thing in its entirety from scratch is not exactly simple!

    None of this is in any way designed to belittle or denigrate the fantastic work some here on the forums do and post about with regard to the HTML client, but it really would be something if a true HTML5 LOB example could be put together by the Team. Just something whose scope we're all familiar with would be all that's necessary.

    In conclusion, if we want to develop a LOB app with LightSwitch and we want it to be able to run on everything, it has to be done using the HTML Client. Portions of it wouldn't translate well to mobile, but then we wouldn't want all of it to do so. However, all of it should be useful on a desktop!

    With regard to the SL Client, we are told that support for SL runs until 2021 (I believe). If that's the case Team, then PLEASE, PLEASE sort these issues that you have been aware of for a very long time!


    Ian Mac

    Saturday, September 21, 2013 4:08 PM
  • We've filed the following connect issue and provided a sample project.

    Saturday, September 21, 2013 4:18 PM
  • It all helps!

    Ian Mac

    Saturday, September 21, 2013 5:04 PM
  • Microsoft will support the silverlight until 2021 how wonderful!
    We are in 2013 and they can not even fix the bugs of performance,
    that the developers have already pointed out several times, what kind of support is this??
    what a shame ... stop be inventing fashion and improve what already exists.
    have more respect for their representatives (the developers)
    Saturday, September 21, 2013 8:35 PM
  • Serious bug in IDE causes slow-down and hangs in HTML client for REAL application (not demo-ware)!!

    Do you think that will get more attention, perhaps?

    Just to make it clear and even more simple to reproduce. Try Contoso and HTML client, yes do go ahead. Yes same problem with Desktop client.

    Go to entity designer for Contoso Appointments. Edit every property and change the 'Display Name' so that it does not default, my suggestion is add a colon ':' at the end. Think REAL world stuff here trying to do ($xxxxxxxx) if you think my changes are stupid.

    Result: Oh dear, first update of a HTML screen in designer stalls with cpu churning for a few seconds. Second update, just milliseconds.

    Please, please, please at least respond and acknowledge the problem. It is getting embarrassing the lengths we have to go to. We are not ever going to let this problem be ignored any more.

    Real users are stuck with applications on LightSwitch V2. The only way forward is to abandon LightSwitch and use another tech stack like some users already have.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Monday, September 23, 2013 12:52 PM
  • Hi mf_falkao,

    I am not able to add any comments or workaround info to the connect problem.

    If you could find the time to add a comment that would be great! It is reproducible with a Contoso project HTML client and Desktop client screens in V3/V4 project versions from VS2012 Update - VS2013 RC. Just add values for 'display names' for all an entities properties.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Monday, September 23, 2013 3:28 PM
  • Hi mf_falkao,

    I am not able to add any comments or workaround info to the connect problem.

    If you could find the time to add a comment that would be great! ...

    Done. I would also suggest that those affect should confirm this in the connect issue.
    Monday, September 23, 2013 7:21 PM
  • Thanks for that, I tried updating the connect issue over the weekend but my comments never seemed to get committed.

    I have confirmation that the problem is being investigated and hope to get confirmation soon that support has reproduced the issue.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Monday, September 23, 2013 7:25 PM
  • David, thanks for giving us solid repro steps -- I can confirm the team has reproduced the issue here and is actively investigating.

    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Monday, September 23, 2013 10:21 PM
  • That's great Beth, thanks; really looking forward to a fix on this one!

    Ian Mac

    Tuesday, September 24, 2013 9:11 AM
  • I second that whole heartedly. I did not realise at first the extent of the problem and how many users are affected. A few seconds slowdown you brush off as an irritation and you just think the LightSwitch screen designer is slow :o

    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Tuesday, September 24, 2013 9:38 AM
  • We actually fixed a lot of performance issues a while back but this one eluded us. The trick to the repro was changing the display name in the entity designer, this causes bad perf in the screen designer.

    Thanks again for helping us track this down.

    -Beth


    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Tuesday, September 24, 2013 4:13 PM
  • Actually Beth as a matter of completeness and just to be sure we're all on the same page, this would occur for me whatever was the first thing I did after opening a screen; adding a property, adding a query, changing a label alignment etc.... and yes of course the DisplayName property!

    Ian Mac

    Tuesday, September 24, 2013 6:34 PM
  • Sorry Beth, my bad (I think). I did not notice at first that you and others were referring to changing the displayname in the Entity designer, which gives rise to the problem in the screen designer, which in turn is the cause of the slowdown whenever you attempt the first operation in a just opened screen: is that the conclusion?

    Ian Mac

    Tuesday, September 24, 2013 6:40 PM
  • I think it is ok as in screen designer the 'first update of a screen' has the performance problem and it is the existence of the custom 'Display Names' that causes the slow code to be invoked.

    That said, I did not retest separately but suspect that custom 'Descriptions' may be suspect too.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Tuesday, September 24, 2013 6:41 PM
  • Hi Beth; any updates on this issue?

    Ian Mac

    Wednesday, October 09, 2013 7:38 AM
  • Hi Beth; any updates on this issue?

    Ian Mac


    Ian, if you look at the issue in Connect, on 9/27 Microsoft posted "The fix should be available in the final version of VS2013".
    Wednesday, October 09, 2013 4:28 PM
  • Sorry for forgetting to follow up here. Yes this has been fixed for RTM. Thank you all for helping us track this down!


    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Wednesday, October 09, 2013 4:31 PM
  • Hi, Great news!

    Is there any news on a fix targeting VS2012 as well?

    Cheers

    Dave


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Wednesday, October 09, 2013 4:33 PM
  • Hi Dave,

    We were only able to get this into the VS2013 release in time.

    Cheers,

    -Beth


    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Wednesday, October 09, 2013 5:01 PM
  • Hi Beth,

    Many thanks for the clarification. With regard to VS2012 (update 4 RC), can you give any indication re a time frame for this fix to be incorporated? Several projects we have cannot as yet be converted to VS2013 because of extension incompatibility etc. so hopefully this won't get overlooked?

    Thanks


    Ian Mac

    Thursday, October 10, 2013 9:08 AM
  • Hi Ian,

    We can't make any promises about a fix for VS2012 at this time but we're looking into it.

    What extensions are you referring to? VS2013 hasn't released yet so I expect extensions to be updated quickly after that.

    Thanks,

    -Beth


    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Thursday, October 10, 2013 3:38 PM
  • Hi Beth,

    Firstly, just to be clear: are you saying that a VS2012 fix is not inevitable or that there will be a fix but you can't give a timescale?

    I would point out that the screen designer issue referred to in this thread was not always present, so presumably the problem was introduced in one of the VS2012 updates?

    In VS2013RC versions of VS2012 solutions, at the point at which the 'Home' screen opens, I get this error : "Could not resolve reference property 'ContentItem.View' with reference string 'xxxxxxxxxx'. Reason: 'NoItemMatched'"

    The error refers (via the 'Reference string' attribute) to a non-commercial, community authored extension, but if I take this out of the project I get a similar message for another extension I use.

    Obviously, if the error I mention above in VS2013RC has a general solution, then that improves things somewhat.

    Hoping you can help!


    Ian Mac

    Thursday, October 10, 2013 5:00 PM
  • Hi Ian,

    I can't make any promises about getting the fix for this into VS2012. The fix did make it into VS2013 and will be available at RTM.

    Have you contacted the extension author about this? If they need help troubleshooting their code we can help. I'll see if one of our extensions expert recognizes the error offhand.

    Cheers,
    -Beth


    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Thursday, October 10, 2013 5:27 PM
  • Hi Ian, Beth,

    The problem Ian describes seems to extend to all extensions that I have that target the UI runtime for VS2013 RC projects. Most obvious for us is that our themes worked ok on VS2013 Preview but do not work on RC.

    As far as extensibility goes, screen templates have not worked since VS2012 introduced V3 projects. This coincidentally stemmed back to proprietary changes made to give exclusivity to C1/Microsoft HTML custom controls.

    I have not seen any or heard of anything positive as regards any LightSwitch extensibility toolkit for VS2013. So something has got to give in 8 days when the RTM drops or there will be none of the usual 3rd-party Silverlight client custom controls? At any rate not for 18th October.

    Cheers

    Dave

    ps: hate piggy-backing this on the end of this thread


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Thursday, October 10, 2013 5:27 PM
  • Thanks David for the extra info. I'll pass it along to the team to troubleshoot.

    We are working on releasing the Extensibility Toolkit compatible for VS2013 and it should be available quickly after we RTM.

    Cheers,

    -Beth


    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Thursday, October 10, 2013 5:31 PM
  • Thanks Beth,

    If anyone needs any help reproducing this sort of issue just let us know!

    I was sitting tight here hoping that it was all part of the plan and a new VS2013 Extensibility Toolkit would be the answer. Data source extensions do not have a problem :)

    Cheers

    Dave


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Thursday, October 10, 2013 5:39 PM
  • I was just informed from our testing team that the extension upgrade issue you are experiencing is also fixed in VS2013 RTM

    Cheers,

    -Beth


    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Thursday, October 10, 2013 5:40 PM
  • That's great, thank you again, very much!

    Dave


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Thursday, October 10, 2013 5:41 PM
  • Hi Beth,

    Since your answer has not changed I'm going to have to assume that you mean it is unlikely the fix will be provisioned at all for VS2102. (I am sorry, but your answer wasn't clear, to me at least!)

    Given that that is indeed what you mean, then effectively any LS SL project written in VS2012 that did not exhibit these performance issues before, but now do, must be upgraded to VS2013 RTM when released, except that there then may well be issues with extensions.

    Which begs the question of how further productive development/enhancement/maintenance is to continue in VS2012 on live solutions that can't be converted to VS2013 because of extension issues, can be undertaken when you are waiting 5 minutes or more for a screen property change. I can't believe that it is expected that all developers will immediately leap to VS2013! LightSwitch in VS2012 is supposed to be a first-class citizen, and that should include fixing issues with the SL client designer (in VS2012) , particularly when said issue appears to have been introduced via an update!

    You can see the dilemma surely; a customer might be waiting for an update, which for reasons outlined above, we have to keep doing in VS2012; except that our devs are getting cheesed off, time wasted waiting for screen changes is money lost and our delivery may ultimately be late!

    It may even be that certain solutions may, for a long time, have to be maintained in VS2012 because of the extensions issue. If the fix is not applied in VS2012, what price productivity and investment in that case?

    Thanks

    Update: I noticed that you posted to the effect that "I was just informed from our testing team that the extension upgrade issue you are experiencing is also fixed in VS2013 RTM...", but that was not in direct reply to me; can I just confirm that the issue you are referring to is the 'Could not resolve reference property....etc' at startup issue I highlighted earlier? That, at least, would be some relief!


    Ian Mac

    Thursday, October 10, 2013 8:55 PM
  • Hi Ian,

    Sorry if I'm not being clear.

    1 - The perf bug AND the extension upgrade issues you reported on this thread ARE fixed and checked into main VS2013 RTM

    2- We are not able to promise a fix for the perf bug in VS2012 at this time. There are a lot of moving pieces to the Update 4 release process and although we are trying to get this fix approved, I can't promise we will.

    Your solution will be to download VS2013 RTM on October 18th upgrade your projects then.

    Thanks,

    -Beth


    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Thursday, October 10, 2013 9:05 PM
  • Hi Beth,

    Sorry for being pedantic, I'm a details guy!

    Thanks for making all that clear, looking forward then to RTM!

    I do hope that VS2012 will at some point get this fix, although I understand that you are not in a position to promise this. Personally I have to say it would be very poor form if this were not to happen as I can't imagine, as I previously said, all shops leaping immediately to VS2013.

    Having said that, thank you very much for you and your team's interaction and response to the general issue.


    Ian Mac

    Thursday, October 10, 2013 10:46 PM
  • Hi everyone,

    Just wanted to let you know that we also got this fix into the Visual Studio Update 4 bits! Those bits have not released yet, but will soon. So if you are experiencing this design time performance issue (where using a custom display name in the entity designer causes perf problems when opening screens, like in localization scenarios) then you will need to install either Visual Studio 2012 Update 4 RTM or Visual Studio 2013 RTM. These will both release soon.

    Thanks for helping us track down this tricky perf bug.

    Cheers,
    -Beth


    Senior Program Manager, Visual Studio Community http://www.bethmassi.com http://msdn.com/lightswitch http://dev.office.com

    Monday, October 14, 2013 11:20 PM
  • Aha so you were just teasing re VS2012 fix availability :-))

    Thanks Beth and the Team that's great news!


    Ian Mac

    Tuesday, October 15, 2013 9:04 AM
  • A happy ending!


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Tuesday, October 15, 2013 9:19 AM
  • Hi,

    I’ve just converted my SL LightSwitch projects from VS2012 to VS2013 Update 2 (ver 12.0.30501).

    And, screen designer is very slow.

    On complicated or no complicated screen, it will take 30 – 45 seconds to accept my changes to control’s name.

    Is it what I should expect?

    Regards

    Tuesday, June 10, 2014 4:17 PM