You might recall my previous post on how DevExpress Logify is used to deliver crash reports in demos, runtime and design time tools for many DevExpress products and technologies.
I wanted to share another real story and discuss an idea, which may improve your user experience as well.
06/09/2017, we fixed an issue Model Editor - Hidden items are lost after cancelling changes in the Customization Form (private).
06/28/2017 we published v17.1.4 with these changes.
07/03/2017 (5 days later), we received the first Logify report about the "Unable to cast object of type 'DevExpress.ExpressApp.Win.Layout.XafLayoutControlGroup' to type 'DevExpress.XtraLayout.LayoutControlItem'" error, because our manual and automatic tests did not cover one scenario where the new code stopped working.
07/07/2017, we fixed our code and provided intermediate builds with the fix.
Since that fix, we published 17.1.5, 17.1.6, 17.1.7, 17.1.8 updates, but I still see the same reports in Logify from users sitting on the old v17.1.4 and v16.2.8 with that already fixed bug. For instance, one of our users had this crash 17 days ago, because he is still using that v17.1.4 from 06/28/2017:
Now the improvement idea to discuss with you.
Imagine that a crash report in Visual Studio tells you that there is already a fix in the next product version. Or even more, it accumulates your crashes and says that 9 of 10 hits have already been fixed. Would that proactivity make you a little happier and motivate you to install the suggested update?
Imagine that a crash report in Visual Studio tells you that there is already a fix in the next product version. Or even more, it accumulates your crashes and says that 9 of 10 hits have already been fixed. Would that proactivity make you a little happier and motivate you to install the suggested update?
Please tell me a little more on how you make upgrade decisions in cases like the one I described. I know from many users that this is almost always a business decision so they try to avoid updates until there is a strong reason. On the other hand, even though we do not have Logify integrated in runtime libraries for many reasons, the design time experience still appears to take a good part of the overall development time, especially when you work with visual designers like Model Editor, Application and Module Designers, ORM Data Model Wizard, designers for grid and other data bound controls. Or maybe it is already stable enough for your typical tasks so there nothing much to worry about?
Updating DevExpress components for us is mostly a painful experience. Not in terms of updating projects or our development environments, but deploying it to our customers.
ReplyDeleteWe can only publish via ClickOnce and our customers do wish a deployment per FTP and not having to install 100MB of DevExpress*.dll to their home directories. Therefore we provide a GAC installer which also needs to be updated for every DevExpress update.
From my experience mosty administrators don't know what a GAC is and what to think of such installers. They sometimes don't even have a policy how to update their clients. So we try to update only 1-2 times a year, to not have to deal with the administrators of our customers.
We also tried copying the assemblies to a network share and redirecting them via app.config but with no success.
Don't get me wrong, updating DevExpress is easy and we would do this more often if our deployment would allow it and sadly this sometimes isn't in our hands.
As for the feature itself:
It would be very nice to directly get a message if something is already fixed, but only if designer performances stay stable. We already got issues in one larger project when opening Model.xafml. Takes up to 3 minutes.
Thanks for sharing, Daniel. That's an interesting experience, and I hope that it's not in majority of cases. BTW, did you try Citrix or Windows RemoteApp Server deployment options? Check the https://documentation.devexpress.com/eXpressAppFramework/113244/Deployment/Deployment-Tutorial/Connect-Clients-to-the-Terminal-Server article for the documentation on the latter option.
DeleteAs for the performance, at first glance it should not slow things down. As for your experience, I regret hearing about it - it should not be that way. I hope we can find the cause of this behavior using your update in the https://www.devexpress.com/Support/Center/Question/Details/T565744/model-designeddiffs-xafml-slow ticket. Thanks.
From my point of view sharing is one of the great features we have in the whole DevExpress community.
DeleteWe already have some RemoteApp deployments running. There work fine and are only administrated by us. But there is a whole bunch of customers which only wants ClickOnce setups. They combine it with their own Citrix environments and strongly limit the users home directory where ClickOnce is installed.
If we include the DevExpress assemblies the home dir would grow as ClickOnce seems not to uninstall older versions keeping all the assemblies in the AppData folder.
As mentioned in the other comment, we may not give up on finding another way to load the DevExpress assemblies, which I refer is not a direct problem of DevExpress but more a general .NET topic.
If solved, I will share these results as mentioned.
As for the ModelDesigner, I think this is mostly Visual Studio as the time loading the designer from the tools you've installed with your products work more smoothly.
@Daniel With the network share/app.config have you tried resolving the assembly location in the AppDomain.CurrentDomain.AssemblyResolve event?
ReplyDeleteHi,
Deletewe've tried to redirect via CodeBase inside the app.config as described here: https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/specify-assembly-location
It worked for normal DevExpress WinForms, but not for an complex XAF.
Thanks for the hint, we may try to handle the event and monitor the outcome. If there is a useful outcome we may publish our results, so we can talk deployment strategies as I think everyones main goal should be updating the DevExpress components.
Yes please share your results in a public ticket on the DevExpress KB. This is a very interesting topic and I believe it will help others and have them weight in on the subject. This network shared deployment is on my todo list, but i've yet do start that task.
DeleteAlex
As intersting as Logify looks (not so much for small shops - because of the higher entry barrier) - I have another (for me) very important question. Are you also collecting error information on the model editor we ship with our applications to our customers? That would be a complete No-Go (f.e. if I tell my customers that absolutely no data is automatically transmitted). I am also not really happy that my DevExpress-Installation obviously does so (without the option to deactivate?). There is always a difficult balance between benefits from collecting data and privacy. I prefer them to be transparent and optional (specially for paying customers). Nowadays this is a kind of distinguishing feature.
ReplyDeleteRegards,
Johannes
Hello Johannes,
DeleteCurrently, no UX data is collected from runtime Model Editor or any other runtime features. You can also use uncheck the "Join "the DevExpress Customer Experience and Notification Program" option during the installation step (where you read EULA and press Accept & Install) if you do not want this functionality. Refer to the https://www.devexpress.com/Home/Legal.xml#Customer-Experience page for more details. Let me know if you have any concerns after that.
Hello Dennis,
Deletethank you very much for your relieving answer. That's really ok so (this is a setting where I always opt out by the way).
As a side note: What I would also find ok and interesting (also for my own applications) is some kind of crash reporter (that you will find f.e. in some browser) where you can decide on each crash individually wheter it should be reported or not.
Sorry for double posting, didn't click on reply before.
You are always welcome.
DeleteAs for the crash reporter, according to your little description, it looks very similar to what Logify provides, at least for the backend. It would be great to learn more about its features and main problems it is going to solve before we could completely understand your idea and consider it for the future. Thanks.
I didn't dive to much into this topic, but the idea is that I (and probably others) don't want to give a wildcard permission for collecting all (log) data at one point of time but would be willing to share data on individual problems (exceptions?) that occur during execution. So as a user I would want to be informed that a problem occured that I *can* share with the vendor (by just on more click). This would need to be something for the frontend then.
DeleteThanks for your clarification, Johannes. I see your point now. It may be especially actual for exceptions with DevExpress routines on the top.
Delete