This is a migrated thread and some comments may be shown as answers.

Single DLL for all controls

34 Answers 1713 Views

Let's talk about telerik (the good and the bad)

This is a migrated thread and some comments may be shown as answers.

34 Answers, 1 is accepted

answered on 26 Feb 2006, 07:30 PM

Just to clarify... are you speaking of ASP.Net 2.0's "web resource" capabilities where you can dump all externally referenced files like js, css, htm, etc. into a single dll?

To me it sounds like you want all dll assemblies into one big dll... if so, that I do NOT want... its fine that each product version comes in its own dll which can easily be distinguished from one release to the next via a standard naming convention.

However I DO like the idea of condensing all the external support files (i.e. js, icons, skins, etc) into one big DLL... this would make deployment easier and avoid the common problem of updating the dll, but failing to update the r.a.d.Controls folder contents.

-Mark

answered on 27 Feb 2006, 04:39 PM

Christopher raises an excellent point. Take the new betas (for example): If you tested and wanted to use TabStrip 3.0, but you were not prepared to adopt CallBack 2.0, the current assembly model is okay. If one mega assembly contained all of the latest release products, you would be "forced" to test and upgrade all components with each product update (or just stick with old products until such a time that you could test all of the new products.

On the other hand, I am in complete agreement that managing and maintaining 17 assemblies is cumbersome (to say the least) and makes upgrades difficult (from a Register tag perspective).

Maybe Telerik can offer the mega assembly to full product owners who don't mind having the latest controls and leave the individual controls available for those who want more flexibility.

Microsoft may only release one System.Web.dll, but they update it MUCH less often than Telerik updates their controls (and they tend to provide strong backwards compatibility).

answered on 27 Feb 2006, 07:13 PM

I think the problems with upgrades stem from not strongly-signing assemblies. This is how you end up with a 2.0 assembly here and a 3.0 assembly there. Strongly-signing your code helps maintain upgrade discipline and roll out updates across the board.

Having said this, I don't see a big problem with the array of DLLs we've got right now. They are nicely partitioned as-is.

What does cause us some trouble is CSS. If some element doesn't have enough specificity in its rules set by Telerik, those rules conflict with ours. We have to zero in on the offending CSS rule and adjust it. That makes it difficult to update CSS files once we receive an upgrade. If anyone is doing the same, you'll find it impossible to make such changes if everything gets lumped into a DLL.

My $0.02

Milan Negovan

answered on 27 Feb 2006, 08:30 PM

Hi-

As a user of the suite, I much prefer having the assemblies separate. For me, the ability to apply one-off updates to a single control DLL outweighs the convenience of having only one DLL to update for everything. This is especially so, since the Telerik controls seem to evolve rapidly.

As for strongly-signed DLLs, I'm not a big fan, because they create an extra couple deployment steps which I tend to forget about until after I've broken the site. For non-strongly-signed DLLs, all I need to do is put them into subversion and and forget about them, so they get deployed with the rest of the site---no extra setup required.

-Mike

answered on 28 Feb 2006, 04:23 AM

Again this begs the question... are you speaking of "web resource" dll's OR the actual assembly dlls.

People are just throwing out there that they want "everything" in one OR that that they want to keep the assemblies separate.

I wish that everyone who is commenting would be very specific in what they are specifying... perhaps some of you don't know anything about "web resource" dlls because they are new for dotnet 2.0... they aren't the same thing as the actual assembly dll's (However, if telerik actually did want to, they could make one combined -- and very large -- dll that would have BOTH the resources and the actual dot.net assembly, all into one dll file) - this I am NOT advocating however.

Again, what I am suggesting is that telerik have uniquely named assemblies for EVERY product and EACH release revision of those respective products... furthermore, for each of those assemblies ALSO have a corresponding revision-tied "web resource" dll that has all of the external js, css, skin, dialog.htm, etc. files. This would make the delivery of the products much more reasonable.

-Mark

answered on 28 Feb 2006, 05:35 AM

If nothing else, it is becoming clear that Telerik's current model (though cumbersome for some) has managed to accommodate a wide range of developer desires. Telerik may want to reflect on the "if it ain't broke, don't fix it" mantra for a few minutes.

That said, I am never one to shy away from change that brings improvement. A growing consensus in this thread seems to be that we as developers still want each product delivered separately so that we can more flexibly choose when and what to update/use.

Lots of the frustration with the current model seems to stem from difficulties we have in managing upgrades, hotfixes, and new product introductions. Some of the common complaints seem to be:

Many of us customize the control resource files to fit our unique applications (a good reason not to compile those files) and maintaining those customizations is difficult during upgrades and hotfixes
When applying hotfixes, it is a time consuming task to identify the files that have actually changed (in an effort to avoid replacing files that have not changed so we do not have to modify hotfixed files with our customizations).
The sheer volume of files, folders, and "traditional" assemblies that we have to maintain for each control can be tough to keep up-to-date and deploy (especially if you install the entire suite or manage multiple sites)

I think it will be difficult to please everyone on this one- those that want to customize want the flexibility the current model provides and those that want to use the controls out of the box want to simplify the management process.

Maybe Telerik should think about methods (within the current product model) to manage and deliver hotfixes and upgrades in a way that will be less disruptive to existing projects and easier to deploy to existing sites. I am not sure what that looks like, but I'm sure someone reading may have a thought.

And while this discussion is all well and good, the current system is not terrible for me. I'd much rather have the brains at Telerik coming up with the next great Telerik control than figuring out how to build a tool/process to deliver smoother updates. But that is (as we all say) just my $.02.

answered on 03 Mar 2006, 03:48 PM

Hello All,

A very good discussion, a lot of quality content here. Basically, we have two separate problems:

#1 - Merge all r.a.d.controls in a single assembly (no longer RadTreeView.dll, RadGrid.dll, but rather a single big Telerik.WebControl.dll assembly)
#2 - Merge external resources, like the javascript client-side files and skins inside the assembly of each product.

My opinion on both:
#1 - I believe we would have been better off if we started with a single assembly from the very beginning, but the way things have progressed so far I'm actually inclined to believe that separate assemblies for every control are not such a big deal. Actually, many of you stated very good pros for this approach. There are cons as well, but I'm starting to believe that different assemblies for different controls have much more benefits than I originally thought (thanks once again for all the points you've made)

#2 - This is IMHO a must have - we need to take advantage of the WebResource attribute in ASP.NET 2.0 and package external resources like all javascript files for the particular product and at least one default skin inside the assembly. The benefit - no need to maintain versions for javascripts and you get the "drop from toolbox, F5 and see what happens" experience, which is very good indeed.

One valid remark related to this approach raised by Jon Hobbs - how do we change things if they are packaged inside the assembly? The answer - maybe we do need to preserve the RadControls folder as well - if the control finds RadControls folder, it will read its Skins / Javascript from there, so that developers can easily change the appearance / javascript when needed.

What do you guys think?

Greetings,
Rumen Stankov
Product Unit Manager
telerik

answered on 03 Mar 2006, 06:23 PM

Personally I need to be able to change skin images (e.g. i recently used a tabstrip and needed to remove the line that runs along the bottom) and I assume that some people may need to be able to edit javascript as well.

With regard to the code, wouldn't it be possible to offer a single RADControls.dll as an option but still make each control available as a seperate dll for those that want to use different versions of each control ?

You'll have to excuse my ignorance but I didn't really understand some of your reply because i'm not sure what 'WebResource' is or what 'drop from toolbox F5' etc means.

answered on 03 Mar 2006, 08:36 PM

Rumen:

I agree with you on point number: maintaining separate assemblies for the controls is probably better. The convenience on big .dll is overshadowed by the trouble associated with incremental updates to individual controls.

On your second point: I like the idea of use the WebResource assemblies in .NET 2, but some convention for editing skin files should be made available. I have never had to modify a control's javascript file (nor do I want to), but I have modified several of the themes/skins (or at leased used them as templates for new themes/skins).

I would be completely content if you complied the control's javascript files and (let's say) one default skin/theme and then put the rest of the themes/skins in an editable location.

answered on 04 Mar 2006, 08:54 AM

Hi Jon.

WebResources are a new feature in ASP.NET - Nikhil Kothari from the ASP.NET team has a very nice blog entry explaining this functionality:

http://www.nikhilk.net/Entry.aspx?id=23

If we package at least one skin and all javascript files for the respective product inside the DLL using the WebResources approach, developers will just install our products (by the way, our Q1 2006 installers will automatically add toolbox icons for our controls in VS2003/2005 - more on this here - http://blogs.telerik.com/blogs/atanas_korchev/archive/2006/03/01/145.aspx), drop the product from the toolbox, use the designer to add a few items, press F5 and will see the result. Currently, you need to first copy the RadControls folder.

answered on 05 Mar 2006, 01:52 AM

From my perspective, I can't imagine that I would use a single-assembly approach. Even it Telerik decides to move in this direction, I hope the single assemblies are still available.

Personally, I do enough to extend Telerik's controls via inheritance and client-side scripting that I am almost never completely on the most recent version of all products at once. I remember that I remained on a 2.x version of RadMenu for quite a while after it was released because I had so much code that was based on the old 2.x API.

Sounds like both ,methods have their advantages....I can't imagine Telerik would want to maintain both approaches at the same time.

-Chris

answered on 14 Mar 2006, 09:21 PM

Hello Jon:

The biggest reluctance I have with the single dll approach is that it forces one to always have the latest version of ALL of telerik's products as the ones that are being used in a project.

However, what happens when I make my own tweaks to some of telerik's javascript functions to address a special need I have on say the r.a.d.Editor... What about any custom dialogs that I design? Or what if I design a solution for a customer, and their staff is acclimated to using a r.a.d.Control with it's current functions and dialogs, but subsequently I am asked to add just one additional new capability that is released in a later version of r.a.d.Controls... in this case in order to obtain that new functionality, installing it could affect all of the already existing r.a.d.Controls implemented and thus alter the dialogs or features... sometimes such unexpected alterations (although we like to call them upgraded features) are not wanted by the customers.

Thus, my desire is that I would like to have the single dll idea apply to each individual product and of course be version specific in its naming convention... additionally, having a corresponding webresource dll for each of those main product release dlls will be very helpful as well (I liked the idea of having the abilility to override the webresource dll if necessary by allowing the existance (and automatic recognition) of overrides for things like skins, javascript, custom dialogs, etc. within a r.a.d.Controls library folder.

Regards,

Mark Chipman

answered on 15 Mar 2006, 05:17 PM

I'll second Mark's proposal:

Separate DLLs for each product
Compiled resource files for product javascript and default skins (with ability to override resources as necessary)

A single DLL, while unquestionably more "convenient" in a sense, is not practical given telerik's rate of product upgrades (which is a good thing). There are definitely cases where we as developers can't afford to upgrade and test all of our teleriks products with each release and would prefer to upgrade one or two components at a time.

This has been a good discussion, though, and it is clear there two schools of thought: "All-in-one dll" and "separate product dlls". For real world PROD situations, separate product dlls (with associated resources) seems like the best path to pursue for minimizing risk during upgrades and giving more control over the upgrade timeline to developers.

Thanks~

answered on 12 Jun 2006, 07:46 PM

Sweet. The simpler things are, the better. Here's an example (which I shouldn't even speak about to anyone else, but maybe it'll make somebody else's day).

The other day (last Friday afternoon, late afternoon to be exact) I was just wrapping up a few days of great progress on a project, saving it all the time like I should. The day was nearly over and I decided to start cleaning up the project, since there were a ton of excess files and publishing it was taking too long. So I deleted a bunch of folders in the RadControls folder (which was were most of the excess was), and then went to publish. Build errors. Uh-oh, this ain't a good thing. In fact, my build error was that an .ascx.vb file was nowhere to be found. UH-OH! Noooooo! I apparently had accidentally deleted the folder where every single web user control was located. Yikes. So what was the damage?

Well, there were 15 files in the folder. 3 of them didnt' have separate codefiles, 9 didn't have a whole lot of code, and 3 had several hundred lines of code. Since I had previously published the site to a live web server, I was able to get all of the .ascx files back in the folder (except for a couple that I hadn't yet uploaded), but since the live site was precompiled, all of the separate ascx.vb files were gone. But at least I had the font-end done, and, like I said, most files were highly declarative and didn't have all that much in the vb anyway.

The lesson learned? Well, in all honesty before a site is completely finished I usually don't compile it on the web server and therefore always have a nice backup if something bad happens. Not sure why, but I wasn't doing that in this case. I'm sure I can take other steps to be more careful (and I will now because my weekend sucked because of this). It's strange to me that a person with my experience, who does this on a daily basis, is still capable of making a mistake like this. I'm glad that telerik is taking steps to further simplify an overly simply process.

And while I'm at it, I have my first major beef with Visual Studio. Unlike most Windows file explorers, where deleted items go into the recycle bin, anything deleted from the solution explorer in Visual Studio is gone forever. Unless I missed something while googling. Does anyone else see this as a massive oversight on the part of Microsoft? We're all human, mistakes happen; it would be nice if it didn't cost us several days of programming when they do happen....

answered on 12 Jan 2007, 09:03 AM

Hi Ryan,

That's a great idea and can combine the best of both worlds - separate assemblies for different controls (to optimize size of deployment and minimize dependencies for developers that do not need them) - and one large ILMerged assembly for developers using a lot of telerik controls in a single project - this will produce one large assembly - much easier for deployment.

We are currently testing ILMerge and have a promising start, hopefully we will have progress in this area soon.

Sincerely yours,
Rumen Stankov (MCSD.NET)
the telerik team

www.telerik.com | dnn.telerik.com | www.sharepointcontrols.com | www.sitefinity.com | www.mcmscontrols.com

answered on 17 May 2007, 03:38 AM

Do anyone have any experience with the ILMerge utility? Basically, I have a few modules that I would like to sell which are using a couple of Telerik controls. I didn’t want to install each of the Telerik controls with the modules, but wanted to use ILMerge to put them into one dll (easier deployment and faster loading).

However, the problem is that if someone else place a Telerik .dll in the /bin folder along with my merged .dll the system errors with a ambiguous reference because at run-time both components are being loaded.

Does anyone have any experience with this? I have searched all over the internet and found much on ILMerge (basically merging your own .dlls, but not so much with commercial deployment and 3rd party components).

Thanks for any direction that you may be able to provide.

answered on 17 May 2007, 10:08 AM

Thank you, Brian, for your question.

Indeed, having two assemblies with the same namespace and type name in the same project means that you will get an exception. This a restriction of the framework and unfortunately we do not have much control over it. The only solution is to leave the controls as they are, without using Elmer. This way if another product uses them, there will be only 1 copy in the bin folder. However, both products must reference the same version of the controls. If one is build with menu 3.0 and the other is with 3.2 then one of the products will have to be updated.

In case you have further questions, please, use the this Forum post.

Greetings,
Rob

Instantly find answers to your questions at the new Telerik Support Center