Description:
If you modify an ASP.NET page markup and click the 'Save' tool button (or press the Ctrl+S key combination), the IDE takes much time (20, 30 seconds or even more than a minute) to save a file on a hard drive of your local machine.
Please note that there is another issue that looks similar to this one:
Visual Studio 2013, 2012, 2010 performance is very slow when a page with ASP.NET controls is opened in Designer
However, the sources of these issues are absolutely different. Sometimes they can appear together when you are editing a page and you can think that this is the same issue. It is important to clearly understand what issue you have encountered, because there are different solutions/workarounds.
If you see the following behavior:
- Visual Studio hangs only when you save a file (please note that Visual Studio automatically saves all changed files when you compile a project);
- This occurs always regardless whether you open a page the Design or Split view, or directly edit the page markup;
This means that you encountered the issue described in this article. Please refer to the Solution section and try the suggested approach.
If Visual Studio hangs only when you are changing the page or control settings in the Design or Split view (even if you are using the Properties window to change the settings), but all operates fast if you are editing the Page/UserControl markup and the Design or Split view is not shown, you faced another issue described in the Visual Studio 2013, 2012, 2010 performance is very slow when a page with ASP.NET controls is opened in Designer article.
Answer:
Issue Details
Saving an ASP.NET page at design time is very slow in Visual Studio 2013 (2012, 2010)
If you modify an ASP.NET page markup and click the 'Save' tool button (or press the Ctrl+S key combination), the IDE takes much time (20, 30 seconds or even more than a minute) to save a file on a hard drive of your local machine.
This issue occurs if ASP.NET components are registered in web.config:
XML<pages validateRequest="false" clientIDMode="AutoID">
<controls>
<add tagPrefix="dx" namespace="DevExpress.Web.ASPxClasses" assembly="DevExpress.Web.v12.2, Version=12.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
<add tagPrefix="dx" namespace="DevExpress.Web.ASPxCallback" assembly="DevExpress.Web.v12.2, Version=12.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
<add tagPrefix="dx" namespace="DevExpress.Web.ASPxCallbackPanel" assembly="DevExpress.Web.v12.2, Version=12.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
<add tagPrefix="dx" namespace="DevExpress.Web.ASPxCloudControl" assembly="DevExpress.Web.v12.2, Version=12.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
<add tagPrefix="dx" namespace="DevExpress.Web.ASPxDataView" assembly="DevExpress.Web.v12.2, Version=12.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
<add tagPrefix="dx" namespace="DevExpress.Web.ASPxFileManager" assembly="DevExpress.Web.v12.2, Version=12.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
...
</controls>
</pages>
The issue occurs even if only several controls are registered there. Sometimes the use of third-party assemblies can cause this issue as well (A master page containing DevExpress controls is saved slowly in Visual Studio 2010 if the controls are registered in the web.config file). A master page containing DevExpress controls is saved slowly in Visual Studio 2013 if the controls are registered in the web.config file. We found that if controls belong to different namespaces within the same assembly, Visual Studio iterates through every class several times (for some internal purposes) several times.
Fix for version v14.2+
Starting with version v14.2, we merged namespaces to prevent additional iterations. This completely fixed the issue if you are modifying only the ASPx markup. However, if you switch Visual Studio into either Designer or Split view, the performance issue returns.
We discovered that Visual Studio serializes all public properties of every control in an assembly. Since our controls are extremely customizable, they have hundreds or even thousands of recursive properties. ASPxGridView has more than ten thousands properties! Visual Studio takes significant time to serialize them all. The serialization appears when you save a file. Moreover, even if you switch back to the Source view, this does not solve the issue. The only way to solve it is to close a tab with page markup and re-open it to edit markup if necessary.
So, to resolve the slow saving issue do the following:
- Upgrade to version v14.2. or higher.
- Do not open either Design or Split view. Use only the Source view to edit markup or control settings.
- If you have opened one of the views (e.g., to see control settings in the Properties grid), close the tab with page markup. If you need to continue editing, reopen the markup file and apply the required changes using the Source view only.
Alternatively, you can use the following workaround;
Workaround for versions before v14.2
If you are using a version previous to v14.2, the only way to work around it is to remove the component registration from web.config and register them in page markup:
ASPx<%@ Register tagPrefix="dx" namespace="DevExpress.Web.ASPxTreeView" assembly="DevExpress.Web.v12.2, Version=12.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" %>
<%@ Register tagPrefix="dx" namespace="DevExpress.Web.ASPxSplitter" assembly="DevExpress.Web.v12.2, Version=12.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" %>
<%@ Register tagPrefix="dx" namespace="DevExpress.Web.ASPxEditors" assembly="DevExpress.Web.v12.2, Version=12.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" %>
<%@ Register tagPrefix="dx" namespace="DevExpress.Web.ASPxGridView" assembly="DevExpress.Web.v12.2, Version=12.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" %>
<%@ Register tagPrefix="dx" namespace="DevExpress.Web.ASPxClasses" assembly="DevExpress.Web.v12.2, Version=12.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" %>
<%@ Register tagPrefix="dx" namespace="DevExpress.Web.ASPxCallbackPanel" assembly="DevExpress.Web.v12.2, Version=12.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" %>
Any update?
No, I've tried everyone's suggestions. I've even changed computers. I'm resigned to the fact that's just life using your product.
@Josep
Hi,
We will need more information about the issue that you encountered when using our controls in VS. I have created the following ticket so that we can further discuss this issue:
Saving an ASP.NET page at design time is very slow in Visual Studio 2012 (2010)
@Gerral,
Hi,
It seems that we have already discussed this issue regarding your project in the context of the (Visual Studio very slow after upgrade to 12.2.8) thread. Please update the thread mentioned above, and let us know whether or not you have implemented the suggested solution. If so, please provide us with your comments about the solution.
I greatly appreciate your time and cooperation.
Is there still no fix for this? When I remove the controls from the web config the save is now quick but then I have to put these controls in 3 master pages and all my aspx pages? That seems more work that just waiting for the save.
This has been ongoing for a couple of years and I've discovered that by leaving the controls in web.config and putting ASPxGridView and ASPxEditors at the top of the <controls> section, the save time is greatly improved.
Hello,
Unfortunately, this issue is not fixed yet. Although Microsoft and we are working closely on this issue, currently, I do not have any news about this situation.
@Eric
I wish to thank you for your feedback. While I could not improve saving performance of my test project, I still believe that this information can be useful. This improvement can depend on the combination of controls that are used on project pages. In my case, this change has no effect, but in other projects it can do the trick. I have also shared this information with our developers.
I've had a similar issue and for me it greatly improved by first removing the VMware VS add-in (I simply renamed the c:\Program Files (x86)\VMware\VMware Workstation\Visual Studio Integrated Debugger\ folder to c:\Program Files (x86)\VMware\VMware Workstation\Visual Studio Integrated Debugger1) and then similar as Eric suggested moved AspxGridView, AspxGridLookup, AspxEditors (in this order) to the top of the include list in the web.config.
Is there any news about this issue?
Hi, We have submitted this issue to Microsoft and are waiting for word from them. As soon we have an update, we will update this ticket, thanks.
Looks like I've faced this issue with Visual Studio 2013 too. This issue is very old, are there any chances it will ever be resolved? Has there been any progress during the last 10 months?
My notes on the problem: the issue seems to go away for a while if you close and restart VS (for me, at least). This also seem to start when you edit an ASP.NET page for a while (about 30 minutes), especially after copying/cutting and pasting DX controls markup on a web page or after changing their server-side properties in the markup.
Nickolay, Software Architect
ClickHelp - Online Help Authoring
http://clickhelp.co
the problem persists!!!
VS2013 is also very slow when working with design and code view.
Nickolay, I wouldn't hold my breath that devexpress will ever sort this issue out. It has been going on for years and they have no answer for it. Every suggestion they have doesn't work, besides the option of creating user controls which is an enormous amount of additional work and a complete waste of time. I've stopped using the devexpress controls over the past few months as I ended up spending half my development time waiting for pages to refresh.
Hello All,
We are aware of this issue, but a solution depends only on our resources. I am personally watching on this issue progress and will immediately inform you when I have any news.
Please also note that this issue is not related to the one described in the Visual Studio 2012 (2010) performance is very slow when a page with ASP.NET controls is opened in Designer article. While they look similar and both influence IDE performance, causes are different.
Vladimir, the point is that your controls are unusable.
If a solution depends on your resources, I suggest have it sorted out!
You offer first class support but it's just impossible to work on a webform with more than 4 of your controls on it. It's not hard to see how many people have struggled with this issue, just search "devexpress slow" and you will find a LOT of search results.
We tried with lots of frustration to understand. It was so frustrating that it took 30-50 seconds each time you tried to move between properties. I am not sure why and how anyone is even using these anymore. Whole point of using devexpress is to cut development time by using controls pre built by someone. If we have to build the controls on top of devexpress why would we not build them from scratch or extend MS controls…
Frustrating part is Devexpress team just does not seem to accept some core issue in their controls and we think they never will.
We migrated to Telerik controls which does not seem to have the issue…
Hello everyone.
We been long awaited a possible solution to the problem, which has been working with VS2010, VS2012 and now also with VS2013.
When projects are large and there are many controls development becomes almost impossible.
Can I certify that Telerik you can not have this problem?
Guys,
I think that your comments will be removed/moderated soon, because it's against the rules to discuss competitors' products here :) However, I think I can share some tricks based on my experience with DX controls (I've been using them for several years).
Indeed, performance issues sometimes kill all the benefits in some cases (but hey guys, not always, it's not that bad!). I've seen pages with 500-900 Kb (don't remember exactly) of viewstate introduced by several ASPxTreeList instances on a single page (and the amount of data in each instance was not very significant - about 20 or 30 nodes). I've seen a page with about 250 Kb of DX scripts (in gzip(!) - the real size of the merged script file was more than 1 Mb) and 170 Kb of DX styles (also gzipped). I've seen slow callbacks caused by viewstate size and some strange server-side handling which I was unable to narrow down or profile properly. I've seen pages which refresh for minutes in debug mode (but work fine in release builds). I've seen Visual Studio loading debug information for my user controls for minutes (I cannot prove that it's related to DX, but all general advices I've found on stackoverflow did not help and this does not happen in my other project, which does not use these controls). Also, I've seen a lot of horrible several minute slowdowns in Visual Studio: in Design mode, during page refresh, during debug, during saving, etc.
The solutions/workarounds were different each time. Note that I don't take general things like "too many DB requests in back end" into account, I talk only about DX-related issues. I'll share some of my tips here just to prove that it's not always that bad:
- ViewState. there is a nice Firefox plug-in to track ViewState size for the current page:
https://addons.mozilla.org/en-US/firefox/addon/viewstate-size/
If you see big numbers for your pages - you're in trouble. Everyone knows how to disable ViewState, but did you know that you can compress ViewState and decrease its size dramatically for all your pages just with a few code lines? All your controls will still work without problems, as if ViewState is enabled (I've checked that myself). However, this will require inheriting all your pages from a single class. See details here:
http://www.codeproject.com/Articles/14733/ViewState-Compression
- DX scripts and styles. There isn't much you can do here, except for enabling the recommended web.config settings. I can't find a proper KB article regarding that, but here's a support case with all the four magic settings and a link to "learn more":
http://www.devexpress.com/Support/Center/Question/Details/Q25965
In my case, resources size is still too big even after compression, so I think that they need minification badly, but I don't think DX will ever do this. However, you can apply bundling, minification and compression to your own styles and scripts and this will also help. Here are some links:
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
http://stackoverflow.com/questions/702124/enable-iis7-gzip
- Slow callbacks. Well, the general idea is: minimize round-trips count and use more client-side logic. I tend to put more and more logic in the client-side part of my custom controls and I'm very happy with my performance results. A few more ideas I use: 1) prevent server-side controls from loading data if the callback will not update them. Imagine a callback which should update a single label on a page and a customer which will wait for this callback to end, while your server side code fetches a database and populates 4 grid controls with data 2) Don't want to fine-tune your callbacks and data loading? Move complex controls to a separate page and insert the content as an iframe to the original page. This way, the back end of these controls will never be invoked until the iframe is refreshed. Other callbacks on the parent page will not affect them. This approach has some limitations, thoug.
- Visual Studio slowness: debug, saving, etc. Well, three suggestions:
- Still does not help? Hey, you don't have to pay to competitors :) Really, HTML 5 is here and there are tons of lightweight free JS controls nowadays, including controls tailored for mobile devices. Even if you don't want to use HTML 5 or don't want to deal with browser quirks in JavaScript, there are a lot of libraries like jQuery which make all this stuff easier. For example, just type "free jQuery controls" in Google. Take a look at our website: htttp://clickhelp.co/ - unlike our application, it does not use DX controls or other heavy server-side controls and I think its performance is nice. The more control you have over the scripts, styles and markup generated, the better performance you can get (if you know how to avoid common performance problems).
P.S.: I'm not protecting DX - I do think there are a lot of things which must be done with performance (scripts/styles minification, issues in VS, like this one, etc.). However, I'd like to point out that any heavy page with a lot of server-side controls and callbacks will work slowly. It does not really matter what vendor you choose - any of them have their own skeletons in the closet. Even if you write the controls yourself, I doubt that they will do the same things much faster.
The only "silver bullet" I have is pure JS controls with server-side code which generates input params as JSON for them. This makes your pages super-fast: no problems with VS, no problems with page refresh, no problems with end user performance.
Nickolay, Software Architect
ClickHelp - Online Help Authoring
http://clickhelp.co
I have read the comments and I am not happy with what I am reading. Nickolay while I appreciate your suggestions for mapping drives differently and using RAM, that is ridiculous that developers have to reconfigure their machines to solve the issues that is occurring with Devexpress, and is related to only Devexpress controls. My development machine is far superior to anything that most developers use. I run 64 gigs RAM, dual 4770k Core I-7 Processors on a high end gaming motherboard with high end graphics. I am running on SSD RAID Drives as well as independent drives. I develop large Enterprise Applications. I am a Microsoft MVP, Certified Developer and Architect. I have also been using Devexpress for 8 years. I also have licenses for all of large control development companies out there. I am using VS 2013 Ultimate. I never have a problem with saving or lagging within Visual Studio with any controls, except with Devexpress. This has nothing to do with my hardware, my skillset in application design, my system configuration, etc. It rests completely within the Devexpress controls, especially with their ASPx control set. I do not have the issues with anything else that I use. I have been waiting years for the issue's to be resolved, yet I keep reading "Well we cannot reproduce it!". Horseshit. It is time that this is fixed and resolved. I love and use the Devexpress controls all the time, but lately I am becoming very frustrated. The argument that you shouldn't use a lot of controls on a page is not an intelligent argument at all. Today's demanding applications require it as do my clients. I play all the tricks that I can, including using .ascx controls and splitting up layouts with subjective, dynamic inheritance, but this is getting ridiculous. There are no problems with Callbacks and page loading on the production servers so stop eluding to those points and possible solutions. These are design time issues within the IDE we all use and it is frustrating. I will be speaking at Visual Studio Live "Las Vegas", "Chicago" and "Redmond". The topics that I am covering are third party development controls and RAD Development in an every changing landscape. I have a multitude of questions already submitted to me regarding performance of different manufacturers control sets and usability. Devexpress it is time you address these issues and implement fixes.
VS Dev: I don't think they are able to fix this issue without redesigning the controls from scratch.
I'm sure all the support and aspx development people at devexpress know about this issue well and have heard the complaint over and over. (It's impossible that they haven't!) They are just unable to fix it due to the way that the controls were developed.
As unfortunate as it is, you are probably correct in your statement.
I can say that I've had this issue previously, on other PC with Win7 + VS2010, but now using Server 2012R2 + VS2012.4 all works well, а few month already, without doing something special. I don't what to say that OS or VS made difference, just I do not know why it works flawlessly now, with the same project…
This problem has existed since VS2010. That means more than 4 years.
YOU HAVE TO FIX IT!!!
Developers use extremely more time than you have to. Just changing the Width of a Control takes a lot of Seconds.
Reidar
Dear DevExpress:
Are there any plans in the work that you all might fix this problem?
Please DevExpress:
We're spending too much time to change anything!!!
This is the speed you can expect when developing with DevExpress controls on Visual Studio 2012 on a Quad Core i7 with 16GB of RAM (and the reason that I will not be renewing my DevExpress license.)
I love and use the Devexpress controls for years!!! But now I am becoming very frustrated. The use of these controls in an ASPX page has become a cost of time is no longer sustainable. I think I will start to evaluate other controls that do not have similar performance issues, since it seems you do not find any solution.!
Disappointing slow, any updates on this?
Hello All,
It has been a while since I last wrote to you, but the thing is that I didn't have any news to share.
Recently, we had a conversation with Microsoft guys engaged in researching this issue. While they have not managed to find its cause, they decided to increase its priority to combine efforts and escalate the research.
Honestly, I do not know how long exactly it takes when MS says "soon". It is an enormous company, and I am sure that this request is not the only one in their high-priority list. I also do not know how they allocate their resources. We just have their word, but no particular estimate.
So, I strongly recommend using the workaround described in my Answer above. Also, please note that there is another issue that looks very similar though it is not completely identical:
Visual Studio 2012 (2010) performance is very slow when a page with ASP.NET controls is opened in Designer
While the issues looks similar, the provided solutions/workarounds are absolutely different. You could have faced both these issues and think that this is the same problem. However, the issue can be resolved only using different workarounds. Therefore, I have described steps to reproduce the issues in the initial post of this ticket. Please refer to it to be sure that you are applying a solution for an appropriate issue.
I will keep you informed if we have any news about this.
Hi Vladimir,
I'm suffering with this problem not only in Design but Code view too and I've tried everything!
I wondered if the problem could stem from using a table layout for my form? I know DevExpress components have a fondness for rendering as tables, so I'd essentially be developing old school tables within tables?
This is slowing my development process down considerably and I'm almost at the point of stripping out the devexpress components and switching to something else as the save delay is horrendous.
Regards,
Matt
Hi
I totally agree with the last comments. I have renewed my Subscription, but don't understand why this problem can't be solved. If you want us to remove the referencdes from the web.config. file, why do they appear there at the first place?
Hello,
We did updated our project templates and no longer register namespaces in web.config. However, this is so only in the recent v13.2 and v13.1 versions.
Sorry
I not understand this solution.
I send you my config, the master page and my webforms.
what do i need change ?
Thank you.
Hello
I removed the references of controls and the web.config. Now i not recoced the controls in the webform.
I add the controls in the webforms and the master.page, it's ok but it is very slow with save.
Please, what do i can do ? i can`t work well.
i sent to you my proyect, can you change it ?
i hope your answer, it's urgent.
Hello Francisco,
In your web applications, all DevExpress control namespaces are registered in web.config:
<pages validateRequest="false" clientIDMode="AutoID"> <controls> <add tagPrefix="dx" namespace="DevExpress.Web.ASPxClasses" assembly="DevExpress.Web.v13.2, Version=13.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" /> <add tagPrefix="dx" namespace="DevExpress.Web.ASPxCallback" assembly="DevExpress.Web.v13.2, Version=13.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" /> <add tagPrefix="dx" namespace="DevExpress.Web.ASPxCallbackPanel" assembly="DevExpress.Web.v13.2, Version=13.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" /> .......
This causes the issue. To resolve it, it is necessary to remove the 'controls' section and register required namespaces on every page. I have attached a sample where controls are registered in Forms.
I suggest you update your application in a similar way. This operation takes some time, but should solve slow saving issue. After that, required namespaces will be automatically registered when you drag and drop a control from the Visual Studio toolbox on a Web Form.
The last proposed solution (to remove the controls section from the web.config and register the required namespaces on every page) did not improve the speed for me. If I register every control from the web.config on a particular page, should I still experience an increase in speed during editing? Or is the increase in speed caused by reducing the number of controls being registered?
Hello Nathan,
You seem to be facing a different issue wish similar attributes: Visual Studio 2012 (2010) performance is very slow when a page with ASP.NET controls is opened in Designer. While these issues' attributes are similar at first glance, their causes are totally different. The workaround from this article does not solve the other issue.
Even if you say its a different problem, I have the same problems. I am in a phase of the Development where my Clients want to change the look of the pages and it takes me hours to do this (Hours is true). The more devexpress Controls on a page the slower it is.
Hello Reidar,
If you face an issue, described in the Visual Studio 2012 (2010) performance is very slow when a page with ASP.NET controls is opened in Designer article, I recommend you refer to the article and try suggested workarounds. If you wish, you can send us the problematic project (please create a separate ticket for this purpose) and we try to provide you with more particular recommendations.
I am not experiencing the "Visual Studio 2012 (2010) performance is very slow when a page with ASP.NET controls is opened in Designer." problem because I am not using Designer at all. I am simply editing the aspx markup by hand and experiencing long periods of unresponsiveness when saving those changes.
Also, my primary question is whether or not the number of controls is a factor. Is the issue caused by the controls being registered in the web.config, or is the issue caused by a large number of controls being registered in the web.config (whereas if they were registered by each page individually its likely that each page would register only a subset of the total number of controls)?
Hi, in new Microsoft Visual Studio 2013 Update 2 this issue has solved.
Update your VS2013 update 2
http://www.visualstudio.com/en-us/news/2014-apr-2-vs.aspx
Hello,
@Nathan
The saving time depends on the number of controls registered in web.config, but the issue occurs even if not so many controls are registered. It also depends on the count of controls used on a saved page. However, the difference is not so noticeable. Moreover, performance of the same page is different on different computers. Unfortunately, we could not find any other workarounds, just total removing control registration from web.config.
@Andrey,
Thank you for your report. Our MS partners informed us that they are going to fix this issue in Visual Studio 20013, but I do not have any ETA. If the VS 2013 Update 2 contains the fix, this is great news. However, currently I cannot confirm the fix until I perform some testing. I will update this thread once I have any news.
The guys also informed us that they unlikely fix this issue in Visual Studio 2012.
Vladimir,
Were you able to confirm the fix in VS 2013 Update 2 yet? This is an critical issue for my team as well as many others (from the looks of this post).
Thanks
Hi,
Unfortunately, Visual Studio 2013 Update 2 seems to still have this issue. We have been informed that currently this fix is planned in VS 2013 Update 3, but I do not have any additional details.
I am suffering with this problem in VS2010, I have a hunch it maybe due to me opening my project by accident in 2012 at some point but disregarded it.
We plan to move our team to VS2013 soon, do you know when Update 3 is due for release?
Hello Matthew,
I am afraid no. Update 2 was released not so long time ago. So, I think that the next Update will be released after some time.
Please provide us with feedback as you get it.
Our company have some projects with very large amounts of controls (asp.net) on single pages, and those pages are almost impossible to work with.
We have also tried moving the dll references out of the web.config file and into the pages themselves, but that did not help. (Actually feels a bit worse)
Pages with few controls seem to be effected much less.
I’m sure this is a very serious problem for others also. I feel this should be one of DevExpress's main focus points.
Just does not feel like it’s getting the attention it deserves.
Have a nice day.
Quintin
Quintin,
You are right. As this is affecting others. I too have saving issue, I have limited my CTRL+S usage on pages with many controls.
Rick
I second that. This is not getting the attention it deserves. It is a deal-breaker for everyone with a web application project.
Hello All,
I'm personally monitoring this situation. Unfortunately, we do not have much information about it. I will inform you if I have any news.
@Quintin
You seem to have faced another issue:
Visual Studio 2012 (2010) performance is very slow when a page with ASP.NET controls is opened in Designer
Maybe both issues occur in your project. Please follow steps in the initial post of this article to be sure that the symptoms are the same in your project.
I have ben looking at all the comments concerning this problem and we are talking about several pages.
And your comments is not When but if we Get a solution. The new release 14.1 don't give me the thrill
When I have to work that slow.
You have to focus on this problem to Get satisfied customers.
Reidar
been dealing with this for a weeks now as the project I have been working on is too far gone to be using an alternative. I have found a way to improve loading though. If you have a page that is dev express label heavy replace the control with the standard .net one and style it accordingly, my save time has dropped dramatically!
Visual Studio 2013 Update 3 is already out: http://support.microsoft.com/kb/2933779
Vladimir, could you confirm if the issue was resolved in this update?
I need some time to install and test this Update. By the way, I see that this is the Release Candidate version and some changes are still possible.
I will update this thread when I have any results, guys.
Hi Vladimir.
I know you said you will update when you have results, but I was just wondering if you perhaps have anything to report yet?
Very curious (Hopefull) that Update 3 will help with the problem.
Thanks
Quintin
Just to let you all know, that VS2013 service pack 3 is no longer a release candidate and is a final release.
http://support.microsoft.com/kb/2933779
It really sucks to use these control. Only reason I am using them is because they have been there in the project for long. They are bloated controls anyways. I didn't care in the past if the pages were slow to render. But to add icing on the cake now they are slow even to design with, or better even if you just write the markup yourself, they are slow any which way.
Good job DevEx, way to go, now we have such a big customer base, we don't care (SARCASM)
And why blame it on MS, your controls are causing the issue. VS works just as fine anything else. MS should fix it for you (BIG JOKE). Because if DevEx doesn't work on VS, people will stop using VS. Surprise people like me will stop using DevEx not VS.
VS2013 SP3 did not resolve the issue with Devexpress Controls. I would like to know what Devexpress plans to do about this moving forward ?
I'd imagine this is a system configuration issue given there are not more people shouting up about it. I have an office of 9 developers and only two (one of which is me) is seeing this issue.
Best advice which can be read in previous comments is minimalise your page's dependency on devexpress controls.
Hello All,
We have thoroughly tested this issue with Visual Studio 2013 Update 3. Unfortunately, Update 3 does not solve it. So, I still suggest you use the same workaround: remove a common registration of our controls in web.confing and register the controls in Page, Master Page and User Control markup when it is necessary. This helped in all the projects I tested. If you still have difficulties with this workaround, feel free to contact us and send me a sample for research. Please also note that there is another issue with very similar symptoms. However, its cause is different, and this workaround does not solve it. Please refer to the steps above to make sure that you have not encountered this problem.
@Yatish
We clearly understand that this issue is extremely annoying and this makes the situation double hard for us. We are working on it in 'no info' conditions, which requires furious efforts from our R&D team. So, I urge you to refrain from such ungrounded assumptions. I do not list all our steps here to not bother you with useless information, but I assure you that this is one of our most prioritized tasks and many professionals are involved in resolving it.
Guys, as you see, in this situation it is very hard to make certain prognoses. I will update this thread once I have any valuable information regarding this issue.
And as I said before, if you have difficulties with the mentioned workaround, feel free to contact me in this or a separate ticket. In the latter case, please mention that the ticket is related to this issue and my colleagues will forward it to me.
Hi,
What is the fastest way to add registration tags for controls back onto the associated page please?
The slowness in render and save in VS is making it almost impossible to use Devex controls.
Please advise your ETA on a fix.
Thanks
Jeff
Hello Jeffrey,
Moving control references from web.config to the markup of all pages is a routine task, but unfortunately there is no automatic way to do it.
Regarding fixing. We are researching this issue . We seem to have found a way to resolve this issue on our side. Unfortunately, this will cause a Breaking Change. It also has a design-time side effect. Currently, we are working on solving them or reducing their effect.
We plan to release the fix in v14.2. We cannot fix this in the previous versions because of the Breaking Change. I will provide you with additional information when we are close to the release of v14.2 (at the end of November - beginning of December this year).
Hi Vladimir,
Where is the option to make any new controls be registered on the page rather than the web.config please?
Thanks
Jeff
Hello Jeff,
There is no such option. Visual Studio automatically registers controls in page or User Control markup unless the controls are registered in web.config. So, if you remove control registration from web.config, VS automatically starts to register them in markup.
Vladimir Unfortunately this possible solution does not work. I have removed the references from my webconfig and I have registered the controls on pages. My PC is i7 4700, 16GB, 512GB SSD and Windows 8.1 takes more than 10 seconds to save my changes made in either Design or Source mode. Hopefully the 14.2 version has this fixed.
Hello Yoel,
Would you please send me a test sample for research? Currently, we are actively testing problematic projects to see what side effects can occur in version v14.2. I would appreciate it if you send me your sample too. To keep your privacy, you can create a separate private ticket and attach your sample there. Please make sure that there is no private data such as remote database connection strings or passwords. You can simply mention that the ticket is related to this problem and my colleagues will forward it to me.
Good news. I tested the 14.2 Beta and pages that normally take around 10 seconds or more to be saved now take less than one second. The pages with multiples controls and icons associated take around 10 seconds to be completed render the first time, but after this point I can work fast with this page without any delay. Specially saving the page. At this moment I not found any big issue with the controls.
For what it's worth, this was causing huge pain this week with a large page that could not be made into a User Control as suggested because it was just a single FormLayout with many records.
My solution was to remove the "Apply Styles" window that I normally keep open with the Toolbox tab. Note: I had to restart VS as well afterwards to get the benefit.
Hello,
To process your recent post more efficiently, I created a separate ticket on your behalf: T203126: A page design time performance is slow if the page contains an ASPxFormLayout with numerous fields. This ticket is currently in our processing queue. Our team will address it as soon as we have any updates.
This solution requires you to extend the license for a year, downgrade our projects manually or refactor them manually to change the web.config, and manually change all the aspxs.
If you have realised that you have a problem on your release, I think you should release a fix for that version or release the next version for everyone.
Hello Jaime,
To fix this issue, we made tremendous changes in assembly and namespace structure of ASP.NET products. This caused several severe Breaking Changes. If we had implemented these changes in existing versions, they would become absolutely different to their previous minor builds. Thus, upgrading to a new minor version is a rather simple task and many changes are not expected in code. So, we implemented this fix only in new versions.
Does this mean that the 15.2 version has better performance on saving, cause I still have tremendous problems with the speed.
I use Windows 10 on a good computer and devexpress ver. 15.1.8
I have noticed significant performance gain with Visual Studio 2015 with 15.x.
It can still be slow, but it hasn't frozen on me for a while like it did in VS 2013.
Starting with version 14.2, saving performance should be solved in all supported Visual Studios. On the other hand, when we were fixing this issue, Visual Studio 2015 was not released yet. If saving changes is still slow in your projects, would you please send me them for research.
Please also note that there is another issue related to Visual Studio Design mode. It also affects page performance and looks the same at first glance. However, it has a different cause; see Visual Studio 2013, 2012, 2010 performance is very slow when a page with ASP.NET controls is opened in Designer for details.