Curl up in front of a roaring fire with our EULA

01 February 2010

OK, the headline is said partly in jest, but the intent is serious. You see, we had a weird support case over the weekend where tempers were starting to rise, until Alex in support worked out what was going on.

The customer was writing a small test program with ASPxScheduler. Worked fine on his development machine — yes, it's the perennial programmer's excuse Smile — but when he copied the test app over to the production server with all required DevExpress assemblies and ran it, blam, the Yellow Screen of Death. The error was frankly bizarre: "Make sure that the class defined in this code file matches the "inherits" attribute, and that it extends the correct base class." Nice, but what the … does it mean?

Of course, the support team couldn't replicate the problem either (more "works on my machine" in other words). We thought it was one thing and then another, nothing seemed to make sense, and every back and forth would dial up the frustration and the tense atmosphere towards the magical 11. Even Mehul was dragged into the fray, and he's in Paris.

Finally this morning, Alex noticed something in a screenshot: the customer was copying the *.design.dlls to the production website as well. The customer considered them part of the "required DevExpress dlls" and had unknowingly copied them over along with the run-time dlls. Our support guys, knowing the language in the EULA, had naturally assumed that this wasn't the case and so were trying more and more outlandish scenarios trying to replicate the customer's problem. Removing the design-time-only dlls solved the issue.

The moral of the story is this: the EULA not only defines your rights and ours and is admittedly quite boring to read, but it does also define a long list of dlls that you can — are allowed to — deploy along with your application. None of the *.design.dlls are deployable.

So, take a moment to read our EULA. You may save yourself some support time in the future…

18 comment(s)
Shaw Innes

I use the controls on a virtual private server and I run 3 or 4 sites on there, so instead of uploading the DLL's to every site individually I like to drop them in GAC.  I'm always very careful to make sure I don't put the .Design.DLL ones on there, but something that would be immensely useful would be if registered subscribers were able to download the distributable DLL's separately to the full development package (2-300mb).  

For example - that way when DX 9.4 comes out I can RDP to my server, login to my DevExpress profile and download a zip or exe or msi or whatever and it can load the various DLL's into the GAC - or at least unzip them so I can do that myself.

1 February, 2010
Schabse Laks

How could the mere presence of the DLL cause the error?

1 February, 2010

The deployment of the dll's has always been a headache instead of falling back on a legal document to stave off a feature requirement just build a utility that scans the projects and builds a zip of the dll's the project specifically requires.

Sounds like a solution to me and we all win.  Oh yeah you replace all that legal text and waste of space with that long list of dll's you have to maintain with...see DLL Deployment Utility.

2 February, 2010
Luke Grews

How about a separate ASP/WPF/Winforms...etc. runtime DLLs folder in that does not include design DLLs in

C:\Program Files\DevExpress 2009.3\Components\Sources

for the next 9.3.3 :)...

2 February, 2010
Mehul Harry (DevExpress)

Deployment Topic in the help file, FTW! Smile|P5|0&d=128

2 February, 2010
Peter Thorpe

@shawn I agree it would be a nice deployment option to have an installer just for the runtime dll's. I would want the option of GAC or xcopy though as I tend to xcopy for programs on network shares.

At the moment my workaround is setting copy local on required devexpress dll's to true and copying the deployment directory. But this makes my project folder large especially if not building all of a solution to the same folder.

2 February, 2010
Ben Ark

There are several support tickets where other people have asked for what Shaw and Luke are asking and the response has often been "search the documentation for Deployment."

Maybe I'm dense but I've looked at all 20+ "Deployment" help topics and never gotten a complete understanding of the full set of DLLs that were redistributable. At one point I had a convoluted spreadsheet of all the different Xtra packages and ASPx packages and what DLLs were needed for the web servers versus desktops. It has always been a mess. Add in new product lines and it's enough to make your head explode.

I never would have though to re-check the License Agreement document. Excellent tip. I suggest adding this to the Deployment documentation. It's a lot more black-and-white than anything else I've read.

We deploy dozens of apps to our internal users built on DX controls via ClickOnce and the Copy Local approach creates deployment bloat and slow install time. So, every time we start a project with a new version of DX, we create an MSI with the DX DLLs to get added to the GAC. We then push out the MSI via GPO. Now I know I can just check the License Agreement to pick up any new DLLs that may have been added in the release.

I think you'll find that my situation is not unique (look at three of the previous comments and numerous support tickets). A new tool (like the Theme Deployer) to create a runtime deployment package may be an excellent addition.

2 February, 2010
Steve Hudson

I would also recommend you check for these .dll's and throw an exception more like "File *.design.dll can not be deployed to a server. " instead of  "Make sure that the class defined in this code file matches the "inherits" attribute, and that it extends the correct base class."

The customer probably could have solved his own problem if the exception message made sense.

2 February, 2010

These situations are great for a vendor to realize a problem THEY need to address, not the customer.  I bet 99% of your own staff don't know what's in the EULA.  Admit it - NO ONE reads EULA's!  They are for attorney's only!  

I have suggested this in the past and you'll keep hearing it until you implement it, you need a "server install" of your products that installs everything needed for any ASP.NET use.  This would GAC everything and we would no longer have to worry about /bin folders and DLL's, etc.

So consider these situations a reflection of the vendor, the customer is only the mirror.

2 February, 2010
Rick Bartlett


Well said. I agree 100%

2 February, 2010

Wouldn't even something as simple as a batch file that copies only the deployable .dll files to a directory be preferable to the way it is now.  

Just asking for a really simple way that a developer can have a folder that only has the deployable dll's without having to figure it all out.  

It's come up several times for me.  So a simple solution would be nice.

3 February, 2010
Aaron Smith

You know what I do? I select all the references in my project, right click, go to properties, and set the Copy Local to true.

Problem solved. No server install needed. The design DLLs are never in the reference list, so they never get copied. When I build, everything goes into the bin folder. I also never have to worry about which version is there, or if I need to update all web projects on that server, etc etc.

3 February, 2010
Miro Nagy

I like the idea of getting the proper dll's getting copied for you into the bin folder.

3 February, 2010
Rollie Claro

very very seriously funny.

There was this occasion where a customer was complaining her cant download the updates. the matter escalated to the superiors and after some deliberation and heated arguments, it turned out that the customers network cable was unplugged from the server.. yikes!!

I salute DX for the patience they put up to us. Admittedly, we are software developers but at times we become exactly just like one of our customers :)

6 February, 2010
Rumen Stankov

One more side-effect of the DLL hell you created. By the way, by no means "extra" DLL should be producing this type of error. I mean come on, every time you got errors like that you go and read EULAs? What are you trying to say, this does not make any sense at all.  And how exactly the design time dll produces this type of error?

By the way, this is not the first time I am dumbfounded by some of the posts you guys write, sometimes I think it is better that you just do not write this stuff at all, even though I believe in open channels and communication.

6 February, 2010
Michael Proctor [DX-Squad]

It is stated in the Deployment articles quite plainly what is required for what scenario with a nice matrix table, surely your project isn't changing that often that every build you have to "recalculated" what distributables you need? if so, that could be your first problem ;)

It is also very clearly stated at the bottom of those articles under the header of Non-Redistributable Libraries, which quote:

"Distributing any DevExpress design-time libraries ending with ".Design" (for instance, DevExpress.XtraReports.v9.3.Design.dll, DevExpress.XtraEditors.v9.3.Design.dll and DevExpress.XtraPrinting.v9.3.Design), is strictly prohibited.

Please consult the EULA for additional up-to-the-minute information on which libraries, tools and executables are considered redistributables."

So this rubbish of people complaining about you shouldn't have to check the EULA is a mute point, it is quite clearly stated in the Help document specifically on deployment which provides you a clear and precise way of know when you will require a library to be distributed.

An example of why these "Matrix" tables are essential to be looked at for your program is XtraReports, if you are using the End User Designer or have charts in your reports will greatly increase the amount of libraries you need to deploy, however if your app has some simple standard reporting then you don't require the libraries, it is very well explained in the table.

Example of XtraReport Deployment Help Article

I would urge anyone who is deploying their app to take the time to calculate what libraries you will need. As some people have mentioned here using the Copy Local in VS is certainly a way to identify what libraries are required.

Just my two cents.

6 February, 2010
Chris Walsh [DX-Squad]

I really don't know why you insist its a DX issue Neal.  Anyone who changes copy local in VS needs to be shot.  Its fraught with danger and its not up to DX to police EVERYTHING you do, but when it wastes supports time when its plain and simple in the Help, in the EULA, in KB articles the works.  It really isn't that hard.  Sure it would be easier with a "Server Installer" but a server installer isn't the be and end all solution.  What if you don't have admin access on that server? you can't add files into the GAC without admin access.  

9 February, 2010
Rumen Stankov

The defensive standpoint is wrong. All you got is honest feedback how stuff could be easier and in a very positive and constructive way, and you all got defensive and tried to explain how it is normal that developers read EULAs every time they get exception, even though none of you guys does that, cause it is just nonsensical.

You should be like, alright guys, we understand, your points are okay and we will do our best to address them. But you are all like "READ THE EULAs". This does not help anyone here.

Cause we will be reading someone else's EULAs with this kind of attitude.

9 February, 2010

Please login or register to post comments.