Single DLL for all controls

35 posts, 0 answers
  1. Stephen Hendry
    Stephen Hendry avatar
    36 posts
    Member since:
    Apr 2004

    Posted 25 Feb 2006 Link to this post

    Ok, I know its a big change, but trust me, maintaining a lot of assemblies and hotfixing 'em aint no easy job.

    I'm avaluating r.a.d.tabstrip 3.0 and putting r.a.d.multipage in the same assembly is a very good move - yes, breaks background compatibility and I need to change my register clauses, but one less assembly to maintain (update, put to toolbox, know all the versions of all controls, etc) is a huge pain for me.

    So here is the suggestion -release one single dll called Telerik.WebControls.Dll for all controls in the page with one version and spare us all the pain of assembly maintenance.

    What do you guys think about that?
  2. Mark Chipman
    Mark Chipman avatar
    219 posts
    Member since:
    Nov 2004

    Posted 26 Feb 2006 Link to this post

    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
  3. Arno Nel
    Arno Nel avatar
    1 posts
    Member since:
    Feb 2006

    Posted 26 Feb 2006 Link to this post

    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
  4. Julian Voelcker
    Julian Voelcker avatar
    156 posts
    Member since:
    Jan 2006

    Posted 27 Feb 2006 Link to this post

    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
  5. Joop Dykstra
    Joop Dykstra avatar
    7 posts
    Member since:
    Feb 2006

    Posted 27 Feb 2006 Link to this post

    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.
  6. Christopher Blickley
    Christopher Blickley avatar
    202 posts
    Member since:
    Jan 2004

    Posted 27 Feb 2006 Link to this post

    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. 
  7. Todd Anglin
    Todd Anglin avatar
    2040 posts
    Member since:
    Aug 2005

    Posted 27 Feb 2006 Link to this post

    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).
  8. Julian Voelcker
    Julian Voelcker avatar
    156 posts
    Member since:
    Jan 2006

    Posted 27 Feb 2006 Link to this post

    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
  9. Ronnie Pisani
    Ronnie Pisani avatar
    4 posts
    Member since:
    Dec 2005

    Posted 27 Feb 2006 Link to this post

    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
  10. Mike Bridge
    Mike Bridge avatar
    96 posts
    Member since:
    Oct 2005

    Posted 27 Feb 2006 Link to this post

    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
  11. Alfred Ortega
    Alfred Ortega avatar
    193 posts
    Member since:
    May 2005

    Posted 27 Feb 2006 Link to this post

    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
  12. Mark Chipman
    Mark Chipman avatar
    219 posts
    Member since:
    Nov 2004

    Posted 27 Feb 2006 Link to this post

    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
  13. Todd Anglin
    Todd Anglin avatar
    2040 posts
    Member since:
    Aug 2005

    Posted 27 Feb 2006 Link to this post

    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.

  14. Jon Hobbs
    Jon Hobbs avatar
    14 posts
    Member since:
    Mar 2005

    Posted 28 Feb 2006 Link to this post

    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 ?
  15. Rumen
    Admin
    Rumen avatar
    1536 posts

    Posted 03 Mar 2006 Link to this post

    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
  16. Jon Hobbs
    Jon Hobbs avatar
    14 posts
    Member since:
    Mar 2005

    Posted 03 Mar 2006 Link to this post


    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.
  17. Todd Anglin
    Todd Anglin avatar
    2040 posts
    Member since:
    Aug 2005

    Posted 03 Mar 2006 Link to this post

    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.
  18. Rumen
    Admin
    Rumen avatar
    1536 posts

    Posted 04 Mar 2006 Link to this post

    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.
  19. Mark Chipman
    Mark Chipman avatar
    219 posts
    Member since:
    Nov 2004

    Posted 04 Mar 2006 Link to this post

    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
  20. Rumen
    Admin
    Rumen avatar
    1536 posts

    Posted 04 Mar 2006 Link to this post

    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
  21. Christopher Blickley
    Christopher Blickley avatar
    202 posts
    Member since:
    Jan 2004

    Posted 04 Mar 2006 Link to this post

    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
  22. Jon Hobbs
    Jon Hobbs avatar
    14 posts
    Member since:
    Mar 2005

    Posted 14 Mar 2006 Link to this post

    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 ?
  23. Vassil Petev
    Admin
    Vassil Petev avatar
    1765 posts

    Posted 14 Mar 2006 Link to this post

    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
  24. Jon Hobbs
    Jon Hobbs avatar
    14 posts
    Member since:
    Mar 2005

    Posted 14 Mar 2006 Link to this post

    Ah right, in that case I vote for a single DLL, much quicker and simpler :)
  25. Mark Chipman
    Mark Chipman avatar
    219 posts
    Member since:
    Nov 2004

    Posted 14 Mar 2006 Link to this post

    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
  26. Todd Anglin
    Todd Anglin avatar
    2040 posts
    Member since:
    Aug 2005

    Posted 15 Mar 2006 Link to this post

    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~

  27. Shaun Peet
    Shaun Peet avatar
    571 posts
    Member since:
    Aug 2004

    Posted 15 Mar 2006 Link to this post

    I'll third Mark's proposal (and second Todd's).  Definitely the way to go for the future.
  28. Todd Anglin
    Todd Anglin avatar
    2040 posts
    Member since:
    Aug 2005

    Posted 12 Jun 2006 Link to this post

    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~
  29. Shaun Peet
    Shaun Peet avatar
    571 posts
    Member since:
    Aug 2004

    Posted 12 Jun 2006 Link to this post

    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....
  30. Ryan Means
    Ryan Means avatar
    32 posts
    Member since:
    Dec 2006

    Posted 10 Jan 2007 Link to this post

    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.
Back to Top