Phill Hodgkinson
Top achievements
Rank 1
Rank 1
Phill Hodgkinson
asked on 24 Apr 2007, 02:13 AM
I recently let my subscription expire with a competitor and purchased RadControls for ASP.Net. One of the things (not the only thing) that made me go with Telerik was the fact that each control was a separate assembly. This meant that if I was deploying a project that only used the combobox I didn't need to upload the entire control library to the production site. In the case of a site built for a client I also feel more comforatable only deploying what they need/use to their server vs. the entire control set.
So when I read about the Prometheus controls boasting "Simpler deployment as all controls are now shipped in a single assembly" as a benefit I'm actually disappointed. Maybe it's just me, but I don't see this as a plus, it's not like uploading 5 files vs 1 is difficult to do, especially when VS will copy required files when publishing anyway.
Otherwise keep up the great work, even though you have made this choice it's still not so bad that I want to switch back ;)
Regards,
Phill
So when I read about the Prometheus controls boasting "Simpler deployment as all controls are now shipped in a single assembly" as a benefit I'm actually disappointed. Maybe it's just me, but I don't see this as a plus, it's not like uploading 5 files vs 1 is difficult to do, especially when VS will copy required files when publishing anyway.
Otherwise keep up the great work, even though you have made this choice it's still not so bad that I want to switch back ;)
Regards,
Phill
24 Answers, 1 is accepted
0
Sopheap Ly
Top achievements
Rank 1
Rank 1
answered on 24 Apr 2007, 02:46 AM
I've mixed feelings about single assembly. It could be easier to just upload one file rather than multiple files. But I think the implication is when you want to use older version of some controls, and the single assembly will force you to upgrade.
There're times that new controls have breaking changes, and you don't have time to make a lot changes to your project soon, so you need to skip it. And then what if the single assembly includes critical bug fixes to other controls? You have no option. You either have to make changes to your project or let your applications vulnerable to attacks.
Anyway, I'm very pleased with telerik efforts. Telerik, you've done a great job in providing superb service to web programmers. And I know you always listen to our suggestions, and that's the reason you're top of the leagues.
Regards,
Sopheap
There're times that new controls have breaking changes, and you don't have time to make a lot changes to your project soon, so you need to skip it. And then what if the single assembly includes critical bug fixes to other controls? You have no option. You either have to make changes to your project or let your applications vulnerable to attacks.
Anyway, I'm very pleased with telerik efforts. Telerik, you've done a great job in providing superb service to web programmers. And I know you always listen to our suggestions, and that's the reason you're top of the leagues.
Regards,
Sopheap
0
Henrik Brinch
Top achievements
Rank 2
Rank 2
answered on 24 Apr 2007, 07:42 AM
It is difficult to please everybody ... however why Telerik has deployed mulitple assemblies might be because they allow you to buy the controls as standalone products. Has Telerik shifted strategy on this on Promotheus? That could sound like that ...
Personally I really don't care if it is one assembly or multiple assemblies (however the later will surely reduce any deployment errors). But I guess if for some reason I really should become to dislike the way it is distributed, I still have the opportunity to compile it myself (though I can't remember if the license does allow this?)
But out of curiosity, why does Telerik not offer both?
Personally I really don't care if it is one assembly or multiple assemblies (however the later will surely reduce any deployment errors). But I guess if for some reason I really should become to dislike the way it is distributed, I still have the opportunity to compile it myself (though I can't remember if the license does allow this?)
But out of curiosity, why does Telerik not offer both?
0
Todd Anglin
Top achievements
Rank 2
Rank 2
answered on 24 Apr 2007, 12:06 PM
Guys-
Thank you very much for your feedback. This has definitely been one of the more disscused issues in the past. People generally fall (passionately) on one side of the debate or the other (you'll notice I was on the multiple assembly side back in February of last year), but we are confident that a single assembly is the best approach for "Prometheus".
The biggest advantage of the single assembly, as you guessed, is a simplified deployment scheme. With a single assembly- and no RadControls directory necessary- deployment will be a simple matter of adding a single DLL to your bin (or GAC) to gain access to all "Prometheus" controls.
Internally, a single assembly also offers a number of benefits to the dev teams that will ultimately benefit you (the developers). A single assembly will allow the controls to easily share common resources, which in turn will help make the "Prometheus" control APIs more consistent from control to control. A single assembly will also help the dev teams ensure to a greater level that all controls "play nice" together an avoid some of the issues with conflicting controls that have been experienced in the past.
All of that said, we definitely want to hear your feedback about working with the single assembly. I know there is some fear of being forced to upgrade all or nothing, but in my own experience I've usually found that when I upgrade the controls in a project I upgrade everything at one time. Let us know how your early tests with the controls go and definitely keep the feedback coming as continue the "Prometheus" beta!
Thanks~
Todd
Thank you very much for your feedback. This has definitely been one of the more disscused issues in the past. People generally fall (passionately) on one side of the debate or the other (you'll notice I was on the multiple assembly side back in February of last year), but we are confident that a single assembly is the best approach for "Prometheus".
The biggest advantage of the single assembly, as you guessed, is a simplified deployment scheme. With a single assembly- and no RadControls directory necessary- deployment will be a simple matter of adding a single DLL to your bin (or GAC) to gain access to all "Prometheus" controls.
Internally, a single assembly also offers a number of benefits to the dev teams that will ultimately benefit you (the developers). A single assembly will allow the controls to easily share common resources, which in turn will help make the "Prometheus" control APIs more consistent from control to control. A single assembly will also help the dev teams ensure to a greater level that all controls "play nice" together an avoid some of the issues with conflicting controls that have been experienced in the past.
All of that said, we definitely want to hear your feedback about working with the single assembly. I know there is some fear of being forced to upgrade all or nothing, but in my own experience I've usually found that when I upgrade the controls in a project I upgrade everything at one time. Let us know how your early tests with the controls go and definitely keep the feedback coming as continue the "Prometheus" beta!
Thanks~
Todd
0
Sopheap Ly
Top achievements
Rank 1
Rank 1
answered on 24 Apr 2007, 02:03 PM
Todd,
It's better to laid in multiple assemblies. Microsoft provides ILMerge tool that you can combine multiple .net assemblies into single assembly. If any user need only one assembly for ease of deployment, they can combine by themselves.
You may then embed a UI tool built on top of ILMerge in the RadControls setup file. If it's easily accessible from Start Menu, i think we will use it. Problem is solved because user can combine different versions of each controls into one assembly for quick deployment.
I hope you still remember that asp.net 1.0 used single assembly, and I believe there were many reasons Microsoft moved from single to multiple in asp.net 2.0.
It's better to laid in multiple assemblies. Microsoft provides ILMerge tool that you can combine multiple .net assemblies into single assembly. If any user need only one assembly for ease of deployment, they can combine by themselves.
You may then embed a UI tool built on top of ILMerge in the RadControls setup file. If it's easily accessible from Start Menu, i think we will use it. Problem is solved because user can combine different versions of each controls into one assembly for quick deployment.
I hope you still remember that asp.net 1.0 used single assembly, and I believe there were many reasons Microsoft moved from single to multiple in asp.net 2.0.
0
Phill Hodgkinson
Top achievements
Rank 1
Rank 1
answered on 24 Apr 2007, 02:12 PM
Hi Todd,
Thanks for the reply and explanation. I understand that it's not an easy decision to make and impossible to make everyone happy.
With that said another thing that I have absoulutely been impressed with is Teleriks response times to client requests in the Forums, on a couple occaions I've even used "special" bug fix interim builds that have gotten me through a pinch. This is a scenario where I feel individual assembly approach really shines and the single assembly approach will no longer be able to provide this custom, speedy response.
I completely understand all the pros, but it would be nice if somehow the comoponents could be dismantelled as well. Can they be compiled individually by the end user if we have access to source control? Then again this would mean a developer would have to send us bug fixed source code vs. a bug fixed dll.
Anyway, I'll leave it at that. It's only my 2 cents out of who knows how many thousands and thousands of cents...
Cheers,
Phill
Thanks for the reply and explanation. I understand that it's not an easy decision to make and impossible to make everyone happy.
With that said another thing that I have absoulutely been impressed with is Teleriks response times to client requests in the Forums, on a couple occaions I've even used "special" bug fix interim builds that have gotten me through a pinch. This is a scenario where I feel individual assembly approach really shines and the single assembly approach will no longer be able to provide this custom, speedy response.
I completely understand all the pros, but it would be nice if somehow the comoponents could be dismantelled as well. Can they be compiled individually by the end user if we have access to source control? Then again this would mean a developer would have to send us bug fixed source code vs. a bug fixed dll.
Anyway, I'll leave it at that. It's only my 2 cents out of who knows how many thousands and thousands of cents...
Cheers,
Phill
0
MB
Top achievements
Rank 1
Rank 1
answered on 24 Apr 2007, 02:16 PM
Todd:
Yep, I can see pros and cons for this.
Bugs aside... The biggest con I see is when a new version implements breaking changes for some controls, but you want/need the new features of other new controls. You can't do a partial or staged upgrade, and you are forced to deal with all the issues in one hit before you can move forward.
-- MB.
Yep, I can see pros and cons for this.
Bugs aside... The biggest con I see is when a new version implements breaking changes for some controls, but you want/need the new features of other new controls. You can't do a partial or staged upgrade, and you are forced to deal with all the issues in one hit before you can move forward.
-- MB.
0
Todd Anglin
Top achievements
Rank 2
Rank 2
answered on 24 Apr 2007, 02:18 PM
Sopheap-
I'm sure there is going to be a lot discussion about this. =)
As I suggested in my last post, there are a lot of development advantages of the single assembly approach that are going to enable Telerik to deliver controls that are more efficient, easier to use (from a developer perspective), and higher quality at release. While ILM can be used for multiple assemblies, it cannot be used enable this common framework and resource sharing that "Prometheus" is adopting. I think the benefits that start to pour out of this new model will really help solidify the value.
Keep the feedback, coming, though. It is definitely important to hear input from everyone as we introduce these new controls.
Thanks~
Todd
I'm sure there is going to be a lot discussion about this. =)
As I suggested in my last post, there are a lot of development advantages of the single assembly approach that are going to enable Telerik to deliver controls that are more efficient, easier to use (from a developer perspective), and higher quality at release. While ILM can be used for multiple assemblies, it cannot be used enable this common framework and resource sharing that "Prometheus" is adopting. I think the benefits that start to pour out of this new model will really help solidify the value.
Keep the feedback, coming, though. It is definitely important to hear input from everyone as we introduce these new controls.
Thanks~
Todd
0
surfer
Top achievements
Rank 1
Rank 1
answered on 24 Apr 2007, 02:24 PM
I typically use 2-3 telerik controls per project, so separate assemblies is the preffered approach in my case. A Single Assembly, though easy to deploy, upgrades all controls and may break existing code (due to bugs or design changes). So if I want to use one new control in the new release, I also have to be absolutely sure that all other controls are backward compatible and do not introduce new bugs, which is very hard to achieve I believe.
0
Todd Anglin
Top achievements
Rank 2
Rank 2
answered on 24 Apr 2007, 02:30 PM
Just a note on what Surfer said-
Even though all of the controls are in a single assembly, if you do not use some of the controls in your project you do not have to worry about debugging those controls in your project. Only controls that you actually use do you have to debug and upgrade. The others will sit "silently" in the assembly and not come into play until you use them.
Thanks~
Todd
Even though all of the controls are in a single assembly, if you do not use some of the controls in your project you do not have to worry about debugging those controls in your project. Only controls that you actually use do you have to debug and upgrade. The others will sit "silently" in the assembly and not come into play until you use them.
Thanks~
Todd
0
Ken Fleming
Top achievements
Rank 1
Rank 1
answered on 24 Apr 2007, 02:57 PM
Curious, but why is there two Ajaxs. Why not integrate RadAjax and Prometheus?
I guess when I get my copy I can compare (hint).
I guess when I get my copy I can compare (hint).
0
Todd Anglin
Top achievements
Rank 2
Rank 2
answered on 24 Apr 2007, 03:12 PM
Ken-
Eventually there will be two of every RadControl for ASP.NET as each is added to "Prometheus". The key difference between the versions is that that client-side programming and Ajax are built on ASP.NET AJAX instead of Telerik's own proprietary client/Ajax layer. Over the next year, you'll see all 18 RadControls gain Prometheus counterparts.
Make sense?
Thanks~
Todd
Eventually there will be two of every RadControl for ASP.NET as each is added to "Prometheus". The key difference between the versions is that that client-side programming and Ajax are built on ASP.NET AJAX instead of Telerik's own proprietary client/Ajax layer. Over the next year, you'll see all 18 RadControls gain Prometheus counterparts.
Make sense?
Thanks~
Todd
0
RK
Top achievements
Rank 1
Rank 1
answered on 24 Apr 2007, 03:16 PM
Thanks, I now have access. Needed to get listed as a developer on the new products.
I did notice that source was available only on ASP.NET RadControls Q1 2007. Is source going to be available on the others? Just curious because having the source has let me figure out why my code wasn't working or where the bug was in yours.
Thanks. I am excited.
I did notice that source was available only on ASP.NET RadControls Q1 2007. Is source going to be available on the others? Just curious because having the source has let me figure out why my code wasn't working or where the bug was in yours.
Thanks. I am excited.
0
Todd Anglin
Top achievements
Rank 2
Rank 2
answered on 24 Apr 2007, 03:19 PM
Ramesh,
Please review the "Prometheus" FAQ here:
http://www.telerik.com/products/aspnet-prometheus/faq.aspx
The source for "Prometheus" will not be available during the beta. Once the suite is officially released and out of beta, the source will be available.
Thanks~
Todd
Please review the "Prometheus" FAQ here:
http://www.telerik.com/products/aspnet-prometheus/faq.aspx
The source for "Prometheus" will not be available during the beta. Once the suite is officially released and out of beta, the source will be available.
Thanks~
Todd
0
surfer
Top achievements
Rank 1
Rank 1
answered on 24 Apr 2007, 03:20 PM
Hello Ramesh,
A lot of questions I've found answered in the Prometheus FAQ located here:
http://www.telerik.com/products/aspnet-prometheus/faq.aspx
Including the source question:
Will you offer the source for the new controls?
A lot of questions I've found answered in the Prometheus FAQ located here:
http://www.telerik.com/products/aspnet-prometheus/faq.aspx
Including the source question:
Will you offer the source for the new controls?
At present our plans are to start offering the source code only when
RadControls “Prometheus” ships officially in early 2008. During the
Beta period we will be offering regular support services, but you will
not be able to download and study the “Prometheus” code base.
0
Sopheap Ly
Top achievements
Rank 1
Rank 1
answered on 24 Apr 2007, 03:51 PM
Todd, the questions I would love to be answered:
Are you going to force clients to update all products at once?
Do you have any solution for clients that don't want to upgrade all at once?
Is it justified to compromise 'flexibility' with 'a little quicker deployment'?
Are you going to force clients to update all products at once?
Do you have any solution for clients that don't want to upgrade all at once?
Is it justified to compromise 'flexibility' with 'a little quicker deployment'?
0
Todd Anglin
Top achievements
Rank 2
Rank 2
answered on 24 Apr 2007, 04:23 PM
Sopheap-
Let me reiterate that the move to a single assembly is for much more than simpler deployment (though that is certainly an advantage). Much of the reason for a single assembly revolves around the overall architecture and performance improvements that it allows the dev teams to make with the controls. Easier deployment is a side effect of the more important technical benefits this new model allows.
I don't have an answer for whether there will be a more flexible model made available for "Prometheus". I will look in to that and let you know. In general, though, the model for "Prometheus" will be single assembly. Hopefully the benefits to the performance of the controls will make this benefits of this model more clear with time.
Thanks~
Todd
Let me reiterate that the move to a single assembly is for much more than simpler deployment (though that is certainly an advantage). Much of the reason for a single assembly revolves around the overall architecture and performance improvements that it allows the dev teams to make with the controls. Easier deployment is a side effect of the more important technical benefits this new model allows.
I don't have an answer for whether there will be a more flexible model made available for "Prometheus". I will look in to that and let you know. In general, though, the model for "Prometheus" will be single assembly. Hopefully the benefits to the performance of the controls will make this benefits of this model more clear with time.
Thanks~
Todd
0
Geoff Van Brunt
Top achievements
Rank 1
Rank 1
answered on 24 Apr 2007, 04:37 PM
One other thing that could come out of the single assembly approach is smaller javascript "files". Shared code could be on the client as well...
I believe this may help many developers who struggle to keep the page size down when using lots of controls. In fact, in the ajax world of the future, I think this concern may outway many of the "benefits" of mutiple assemblies.
I believe this may help many developers who struggle to keep the page size down when using lots of controls. In fact, in the ajax world of the future, I think this concern may outway many of the "benefits" of mutiple assemblies.
0
Todd Anglin
Top achievements
Rank 2
Rank 2
answered on 24 Apr 2007, 04:43 PM
Geoff-
The client-side efficiencies of the "Prometheus" approach are among its chief advantages. Not only will the Telerik controls be able to share scripts (reducing JS load on a page with lots of controls), but because all controls are built on ASP.NET AJAX the Telerik controls will be able to further share scripts with any ASP.NET AJAX control. This is a huge benefit of "Prometheus" since .NET 3.5 (or "Orcas") wll make ASP.NET AJAX a standard part of ASP.
Thanks for bringing up the topic. It's a very good point.
Todd
The client-side efficiencies of the "Prometheus" approach are among its chief advantages. Not only will the Telerik controls be able to share scripts (reducing JS load on a page with lots of controls), but because all controls are built on ASP.NET AJAX the Telerik controls will be able to further share scripts with any ASP.NET AJAX control. This is a huge benefit of "Prometheus" since .NET 3.5 (or "Orcas") wll make ASP.NET AJAX a standard part of ASP.
Thanks for bringing up the topic. It's a very good point.
Todd
0
Kevin
Top achievements
Rank 1
Rank 1
answered on 24 Apr 2007, 05:15 PM
Everyone will agree that a single assembly is better _provided_ upgrades are painless. I've been through several upgrades (including menu 3.x -> 4.x, rad CallBack -> rad Ajax), etc and they have been painful. This pain will be tenfold if it needs to be done for a control you do not even want to upgrade.
But I am sure telerik folks have been thinking about that a lot and the bet to choose a single assembly is also a commitment that the framework is solid and no design changes are expected, so I do support and respect this choice. There are also other pros which have been discussed before.
Btw, this discussion can be moved in the General Discussions "Prometheus" threads... since the long awaited and great Ajax Manager running with the MS AJAX engine gets in the shadows of a discussion which has already been commented in detail before here:
http://www.telerik.com/community/forums/thread/b311D-cmghb.aspx
But I am sure telerik folks have been thinking about that a lot and the bet to choose a single assembly is also a commitment that the framework is solid and no design changes are expected, so I do support and respect this choice. There are also other pros which have been discussed before.
Btw, this discussion can be moved in the General Discussions "Prometheus" threads... since the long awaited and great Ajax Manager running with the MS AJAX engine gets in the shadows of a discussion which has already been commented in detail before here:
http://www.telerik.com/community/forums/thread/b311D-cmghb.aspx
0
Hi all,
Thank you for all your feedback -- it is much appreciated.
We do realize there are pros and cons on the single-assembly approach and we are confident that the pros (code sharing both on the server and on the client, better performance, more integrated features, easier deployment, etc) outweigh the cons. Furthermore, we want to clearly communicate our commitment to backwards compatibility on all controls included in the single assembly. We will do our best to not break any code already shipped in Telerik.Wb.UI.dll and to make your upgrades as painless as possible.
Please, keep your feedback coming -- we are listening.
P.S. This thread has been moved from RadAjax "Prometheus" forum to "General Suggestions" for Prometheus as this is a more relevant place for the discussion.
Kind regards,
Ivo
Telerik team
Instantly find answers to your questions at the new Telerik Support Center
Thank you for all your feedback -- it is much appreciated.
We do realize there are pros and cons on the single-assembly approach and we are confident that the pros (code sharing both on the server and on the client, better performance, more integrated features, easier deployment, etc) outweigh the cons. Furthermore, we want to clearly communicate our commitment to backwards compatibility on all controls included in the single assembly. We will do our best to not break any code already shipped in Telerik.Wb.UI.dll and to make your upgrades as painless as possible.
Please, keep your feedback coming -- we are listening.
P.S. This thread has been moved from RadAjax "Prometheus" forum to "General Suggestions" for Prometheus as this is a more relevant place for the discussion.
Kind regards,
Ivo
Telerik team
Instantly find answers to your questions at the new Telerik Support Center
0
bwood
Top achievements
Rank 1
Rank 1
answered on 07 Dec 2007, 08:38 PM
WELL I have a genuine concern with this one assembly architecture. Why couldn't you guys atleast rename the assembly so it didn't conflict with the other TELERIK.WEB.UI.DLL assembly? The reason I ask is because I had a perfectly working app that used the RadDock heavily. I then read about the new ajax model and upgraded the dll to prometheus. I began to alter my app to use the new radajaxmanager. I had just finished my custom CRM, in which the entire thing felt like a true software application rather than a website. Then I went back to work on some of my webpages that used the RadDock and now my entire RadDock looks way different and is buggy. There is no way for me to upgrade just the radajaxmanager. So now I'm sitting around waiting for support to tell me how I can use both assemblies at the same time. I spend all day researching this with no luck. That cost my boss in $200. Now if Telerik's support gets back to me and tells me there is no way to use both assemblies I'll have to redo the entire CRM. That will cost my boss $1,000 and make me miss my deadline. Great.
0
Todd Anglin
Top achievements
Rank 2
Rank 2
answered on 07 Dec 2007, 11:11 PM
K-
First of all, let me express my sincere apologies for the trouble you're having. It's never fun to be up against deadlines and dealing with confusing issues. Let's see if we can sort this out.
Now unless I'm mistaken, before Prometheus all control assemblies were named after the products. That means pre-Prometheus Dock should have been contained in "RadDock.dll" or "RadDock.Net2.dll". There was no Telerik.Web.UI.dll before Prometheus. That means any pre-Prometheus Dock implementation you had should not have had any Namespace or assembly name conflicts with Prometheus.
In general, you can freely mix and match Prometheus and non-Prometheus controls. That means you can use non-Prometheus Dock and Prometheus Ajax if you want to. You can even use non-Prometheus Ajax and Prometheus Ajax in the same app if you need to during a transition period. How you mix and match is up to you, though it is always recommended to upgrade to Prometheus controls when you have time (since they represent the future of the ASP.NET controls).
All of that said, it sounds like the core confusion is revolving around this mysterious "Telerik.Web.UI.dll" assembly you had that is conflicting with "Prometheus". Can you post more details about its version and build date? With that info I can further help you sort things out.
-Todd
First of all, let me express my sincere apologies for the trouble you're having. It's never fun to be up against deadlines and dealing with confusing issues. Let's see if we can sort this out.
Now unless I'm mistaken, before Prometheus all control assemblies were named after the products. That means pre-Prometheus Dock should have been contained in "RadDock.dll" or "RadDock.Net2.dll". There was no Telerik.Web.UI.dll before Prometheus. That means any pre-Prometheus Dock implementation you had should not have had any Namespace or assembly name conflicts with Prometheus.
In general, you can freely mix and match Prometheus and non-Prometheus controls. That means you can use non-Prometheus Dock and Prometheus Ajax if you want to. You can even use non-Prometheus Ajax and Prometheus Ajax in the same app if you need to during a transition period. How you mix and match is up to you, though it is always recommended to upgrade to Prometheus controls when you have time (since they represent the future of the ASP.NET controls).
All of that said, it sounds like the core confusion is revolving around this mysterious "Telerik.Web.UI.dll" assembly you had that is conflicting with "Prometheus". Can you post more details about its version and build date? With that info I can further help you sort things out.
-Todd
0
bwood
Top achievements
Rank 1
Rank 1
answered on 10 Dec 2007, 03:45 PM
Thanks for the response. For whatever reason, when I replace the telerik.web.ui.dll with the prometheus one my raddocks function and look differently.
But on a good note, I spent only 2 hours to fix all of the issues with the raddock and I now have them working the same as they were in the earlier non-prometheus version. So it looks like my problem is fixed and I can continue on using prometheus.
Thanks
But on a good note, I spent only 2 hours to fix all of the issues with the raddock and I now have them working the same as they were in the earlier non-prometheus version. So it looks like my problem is fixed and I can continue on using prometheus.
Thanks
0
Todd Anglin
Top achievements
Rank 2
Rank 2
answered on 10 Dec 2007, 04:11 PM
K-
I'm happy to hear that you've resolved your problems and are moving forward with Prometheus. In general, Prometheus is a much better choice for RadDock development than the older "classic" versions. Many new features and enhancements were added to the Prometheus version earlier this year that I'm sure you'll enjoy.
If you have any additional trouble down the road, you know where to find help. :)
-Todd
I'm happy to hear that you've resolved your problems and are moving forward with Prometheus. In general, Prometheus is a much better choice for RadDock development than the older "classic" versions. Many new features and enhancements were added to the Prometheus version earlier this year that I'm sure you'll enjoy.
If you have any additional trouble down the road, you know where to find help. :)
-Todd