Single DLL for all controls

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

Id like all resources and all dll'z merged into 1 big dll, if you buy the suite.
if you buy a single component, obviously that should not be the case

I would also prefer to see a single assembly if you have the control suite.

It would also be great to see all the javascript scripts rolled into it as well, unless there are performance benefits of keeping them seperate.

Cheers,

Julian

I don't know about you guys but I am a bit worried that such a move by Telerik might break my existing code. My opinion is that the benefit is there, however, do you think it justifies the extra time we'll need to change our apps?

If Telerik does something like this I will most likely stick to the old versions in all my existing projects and will use the new "mega" assembly only in new projects.

I'm not sure I like this idea too much....while it sounds good and may be appropriate in certain instances, I worry about the upgrade path.  When a new set of products is released, I frequently find myself wanting to upgrade only one or two components at a time.  It may be because of too many backwards compatability issues, or just the time to upgrade if I have a great deal of code to go through.

Just my thoughts, but I kind of like the idea of seperate assemblies right now. 

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).

OK, as a compromise how about some sort of tool to help you ugrade your web projects when a new release comes out with the latest assemblies and scripts so that we don't have to copy them across individually.

Having to check every directory under the Radcontrols directory to see what script files have changed is a bit of a pain, particularly when doing so across multiple sites.

Cheers,

Julian

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

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

I also vote for maintaining the assemblies as separate dll's.  It's easier to upgrade the components I want when I need to and test them individually to ensure everything works as expected.

Al

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

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:

1. 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
2. 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).
3. 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.

I like the idea of having all the DLL's rolled up into one but I don't like the idea of having all the skin files and javascript files etc included, wouldn't that make them un-editable ?

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

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.

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.

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.

Rumen & Todd:

Yes, now your talking about the right direction to go with this... pretty much what I've been advocating all along... except I like your improved idea of having the r.a.d.Controls directory being there to allow for overriding of functionality & css, additional html resources, alternative skins, etc.

That would be terrific.

-Mark

Yep, WebResources support is probably going to be the next major thing going @ telerik immediately after the Q1 release. However, the original topic from Stephen deviated a little - the original question was referring to packaging all assemblies of all controls in a single big assembly and that's the area where we do need to hear more pros / cons so we can decide if we need to do it (and with what priority).


Greetings,
Rumen Stankov
Product Unit Manager
telerik

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

I would definitely use a single assembly rather than installing htem all seperately (one dll per project, fantastic!) , but I really don't see why they can't be offered seperately as well as a single dll, it can't be that much work to offer both could it ?

Well, Jon, it is an extra effort to create and maintain both, they will need testing, the support will be different, etc. So, it is an overhead which we are trying to leverage.


Regards,

Vassil Petev
Client Service Director
the telerik team

Ah right, in that case I vote for a single DLL, much quicker and simpler :)

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

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~

I'll third Mark's proposal (and second Todd's).  Definitely the way to go for the future.

All-

Rob at telerik has said that all of the .NET 2 complied controls in the upcoming Q2 2006 release will use WebResource files. No RadControls folder will be necessary! You can view his reply here.

Just wanted to update everybody who contributed so much input to this big (and much appreciated) shift in the control setup.

Thanks~

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....

The .net tool ILMerge from Microsoft will allow us to take the current Rad assembiles and merge them into a single assembly.  Maybe if Telerik creates a batch file to do this for us each time you release a new version then we can decide to create a single assembly should that fit our needs.

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

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.

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

I want WebControls.dll I can't find it.
please help me to find it.

Hello Amin,

The single DLL for all controls is featured in our Prometheus suite. You can learn more about the new suite here: http://www.telerik.com/products/aspnet-prometheus/overview.aspx. The download is available in your client.net account.

 
All the best,
Rob
the Telerik team