Rank 1
Following an upgrade from the previous version to the latest version, (Q1 2013), I was dismayed to find that several large diagrams that I had painstakingly layed-out and coloured had reverted to an unformatted state. No code changes were apparent in the working copy diagram file on closing the solution.
On a hunch that the new multi-diagrams feature had somehow broken this, I edited the rlinq.diagram file in notepad and enclosed the <entityDiagramsDiagram> top level node within an <EntityDiagrams> node. Opening the diagram in Visual Studio my diagram was restored to its sensible self and I was able to stop hammering the desk with my fist.
7 Answers, 1 is accepted
You are absolutely right, the problem is related to the changed format of the .rlinq.diagram file, required by the multiple diagram support and occurs the first time an existing rlinq file is opened. Unfortunately the only workaround is the one that you have already found out. The existing <entityDiagramsDiagram> root node should be enclosed with an <EntityDiagrams> node. This way the designer is able to serialize the formatting of more than one diagram.
This problem has already been fixed and the fix will be included in the next version of OpenAccess. I will update this thread once the build is available.
Thank you for reporting this issue and please excuse us for the inconvenience caused. Your Telerik points have been updated.
Kind regards,
Alexander
the Telerik team
Rank 1
I was also dismayed at the lost formatting and about to get very upset! Thankfully I just closed the designer and found your post at the top of the forum.
Much appreciated.
Rank 1
Rank 1
Soooo many horribly breaking things that made it's way into the "official release" is one thing...
But, I just can't say enough about how much Telerik NEEDS to come up with a different method for how all these horrible breaking pieces get communicated to users BEFORE they actually install the "official release".
I have just recently "upgraded" to the Q1 release this week (AJAX, OA, REPORTING), and have been doing nothing else this week but diagnosing and filling out support tickets. This is after the "official release" has been out there for a month. If I had known about 5% of the problems that I faced, I would NEVER EVER have done the upgrades. I would've waited for the SP (which...btw is also WAY overdue for the products with these kinds of really bad problems).
I had suggested in one of my many tickets that something similar to "release notes" where the "official install" download is...if we had a link there to UP TO THE MINUTE breaking things in that official release, maybe people could read that and decide, "hmm, maybe I don't want my app to be completely broken right now", and they could avoid all these issues and wait for a SP. EVERYBODY's time is wasted if we don't have something like this (including telerik's, because they have to field and answer the SAME questions over and over.)
There is "breaking changes" in the release notes for the official release... "Breaking bugs" after the release is JUST as important to know.
Please accept our apologies for the inconvenience this upgrade has caused you. Let me shed some light on what we are currently doing to avoid such overhead on your side.
When such an issue appears, it is either handled by a Service Pack or an internal build if it is a show-stopper, or it is described in our resources so that other people can benefit from that information. For instance, the issue you found with the Visual Designer diagrams file has a workaround and we are generally creating Knowledge Base articles for such cases. This time we were late with the article - you can now find it here. We will make sure we react much quicker to such cases after the next official release so that you can just check the Knowledge Base section of our website to see if anything unexpected has been found already.
These resources, together with the Release Notes breaking changes, should provide you with preliminary information on what changes an upgrade might impose on your solution. Of course, we are striving to keep those cases to minimum.
Thank you for the feedback and do not hesitate to get back to us if you have any other ideas about making your experience with DevCraft better.
Ivailo
the Telerik team
Rank 1
When there is a Q release and a BIG problem with that release arises, having a KB article out there a month after the fact obviously isn't a great solution. Moreover, I'm not sure a "KB" article is best area for such things... Maybe for the "solution", but NOT for informing people that there is a big issue. Again, if for no other reason than because other products don't do it that way.
Example...
There was a pretty big RadButton issue in the AJAX release in 2013 Q1. Before installing the "official release" (a month after it is released), should I go to that AJAX KB section to find out what big issues there are, so it doesn't break my application ?? If you do, you won't find a peep about this issue in that KB section. Where is it? It is a sticky note in the Ajax/Button forum. So, now I'm forced to look through 2+ dozen control forums to find out what (major) bugs have been found in an "official release". NOT a good solution.
The goal is to give people the option of NOT installing an "official release" if there are BIG issues that came from that release. I'm NOT talking about "breaking changes" that are documented with the release in the release notes. I'm talking about things that are NOT documented (bugs) that are found after the release is out. We NEED the same quick-list type of information in one place (just like the breaking changes are listed at time of release).
Why can't there be ONE place where these "after-release notes" with breaking things are listed (for each product)... as they are found?? They don't do anybody any good if people install the broken things and read about the broken things 6 weeks after when a SP is released.
I see your point. You are right that having a single place for updates like that would probably save you some time.
We will reconsider our current policy and will search for better solutions that would tackle this problem for the entire DevCraft suite.
Thanks again for the feedback. Once we have a solution we will let you know so that you can take a look and validate it against your scenarios.
Ivailo
the Telerik team