There are some tools out there that promise to shrink the size of your XAP file and also obfuscate the file so that it's harder to disassemble. In this regard I have two questions for those who have tried these tools.
1. How effective are these tools at minimizing the size of the XAP file? What are the techniques used?
2. How secure is the XAP file with and without obfuscation? Is it possible to disassemble the original XAP to the original source code?
1. How effective are these tools at minimizing the size of the XAP file? What are the techniques used?
2. How secure is the XAP file with and without obfuscation? Is it possible to disassemble the original XAP to the original source code?
10 Answers, 1 is accepted
0
Accepted
Hello Jorn,
We don't provide such tools, but I will try to answer your questions anyway:
1) There are several techniques for minimizing the XAP file size:
- the easiest is to enable the assembly caching in the Silverlight application project properties. This will put (e.g. cache) the system or third party assemblies into separate ZIP files that will be downloaded when the application is run for the first time. Generally this optimization will not have effect unless the client uses several applications that use the same cached assemblies.
- since the XAP files are basically renamed ZIP files, there are tools, now obsolete, that used to re-compress them. In Silverlight 2 the XAP files were compressed with very low compression ratio, hence they benefited from those tools a lot. Silverlight 3 uses better compression algorithm so such tools are not very usable anymore.
- there are tools that analyze the assemblies in the XAP file and then remove the unused code. In theory this could have huge benefit for third party control assemblies, because they usually pack a lot of functionality that is rarely used at once. There are several problems with such tools, though - if the code in the application uses reflection, the tool could incorrectly identify parts of the code as unused and break the application. On the other hand such tools cannot process digitally signed assemblies unless you have the digital key, which is not an option with the third party control assemblies.
2) The XAP files are plain ZIP files, hence they cannot be obfuscated. You could use a third party tool (such as Dotfuscator) that will obfuscate the code of your application at compile time. Those tools are quite effective and the obfuscated code becomes virtually impossible to disassemble. The non obfuscated assemblies are very easy to disassemble using RedGate's Reflector or other similar tools.
I hope my answers were helpful.
Sincerely yours,
Valeri Hristov
the Telerik team
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
Follow the status of features or bugs in PITS and vote for them to affect their priority.
We don't provide such tools, but I will try to answer your questions anyway:
1) There are several techniques for minimizing the XAP file size:
- the easiest is to enable the assembly caching in the Silverlight application project properties. This will put (e.g. cache) the system or third party assemblies into separate ZIP files that will be downloaded when the application is run for the first time. Generally this optimization will not have effect unless the client uses several applications that use the same cached assemblies.
- since the XAP files are basically renamed ZIP files, there are tools, now obsolete, that used to re-compress them. In Silverlight 2 the XAP files were compressed with very low compression ratio, hence they benefited from those tools a lot. Silverlight 3 uses better compression algorithm so such tools are not very usable anymore.
- there are tools that analyze the assemblies in the XAP file and then remove the unused code. In theory this could have huge benefit for third party control assemblies, because they usually pack a lot of functionality that is rarely used at once. There are several problems with such tools, though - if the code in the application uses reflection, the tool could incorrectly identify parts of the code as unused and break the application. On the other hand such tools cannot process digitally signed assemblies unless you have the digital key, which is not an option with the third party control assemblies.
2) The XAP files are plain ZIP files, hence they cannot be obfuscated. You could use a third party tool (such as Dotfuscator) that will obfuscate the code of your application at compile time. Those tools are quite effective and the obfuscated code becomes virtually impossible to disassemble. The non obfuscated assemblies are very easy to disassemble using RedGate's Reflector or other similar tools.
I hope my answers were helpful.
Sincerely yours,
Valeri Hristov
the Telerik team
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.
Follow the status of features or bugs in PITS and vote for them to affect their priority.
0
Trude
Top achievements
Rank 2
Rank 2
answered on 05 Feb 2010, 11:22 AM
Thank you - Obfuscation (at compile time) seems like the way to go. I will look into these (or similar) products for my current project.
0
Ben Hayat
Top achievements
Rank 2
Rank 2
answered on 05 Feb 2010, 05:25 PM
Valeri, all your points are 100% and you covered it very well!
0
Daní
Top achievements
Rank 1
Rank 1
answered on 14 Feb 2010, 10:09 PM
I agree with Valeri too. I've tried the XapOptimizer provided for ComponentOne with no success. But I also think telerik dll's are too heavy and can supose an issue when used in internet scenarios. Fortunately, I'm using telerik controls in LAN environments where one extra MB is not an issue, but I tried to simply use the RadScheduler control in a personal application and the xap file passed from 900Kb to 1.7MB... too much for me, I can't understand why I need to reference Telerik.Windows,Data.dll, Telerik.Windows.Controls.Navigation and Telerik.Windows.Controls.Input dll to just use a control. I think a reflexion about this issue is needed from Telerik part. Your controls are really great, but I think using your silverlights controls adds a bandwidth penalty compared with other silverlights providers.
0
Hello DanÃ,
You don't need Telerik.Windows.Controls.Data in order to use RadScheduler. Input is needed for RadComboBox and RadCalendar/RadDatePicker, Navigation is needed for RadWindow and RadContextMenu.
Unfortunately there are several problems regarding the assembly sizes:
1) In order to be competitive, we need to constantly add new features to the controls, which inevitably increases the assembly sizes.
2) We need to add new controls, which also increases the assembly sizes.
3) The new controls and features often use other existing controls (e.g. RadScheduler needs RadCalendar, RadDatePicker, RadWindow, etc.) so usually the bigger controls need the common assemblies (Controls, Input, Navigation), e.g. have bigger foot print.
4) We cannot put the new controls or features in separate assemblies because of those references - for a developer with less experience with our controls it would be extremely hard to add the needed references. The experienced developers would also have difficulties with the maintenance of tens of references that need to be updated once a new SP is released.
Having in mind the above, we tried to make a compromise - put all smaller controls in common assemblies (this reduces the number of references to maintain) while the large controls are in separate assemblies (this reduce the bulk when you don't need them). Unfortunately the scenarios are countless and we cannot provide the best configuration of controls in our assemblies for everyone.
All the best,
Valeri Hristov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
You don't need Telerik.Windows.Controls.Data in order to use RadScheduler. Input is needed for RadComboBox and RadCalendar/RadDatePicker, Navigation is needed for RadWindow and RadContextMenu.
Unfortunately there are several problems regarding the assembly sizes:
1) In order to be competitive, we need to constantly add new features to the controls, which inevitably increases the assembly sizes.
2) We need to add new controls, which also increases the assembly sizes.
3) The new controls and features often use other existing controls (e.g. RadScheduler needs RadCalendar, RadDatePicker, RadWindow, etc.) so usually the bigger controls need the common assemblies (Controls, Input, Navigation), e.g. have bigger foot print.
4) We cannot put the new controls or features in separate assemblies because of those references - for a developer with less experience with our controls it would be extremely hard to add the needed references. The experienced developers would also have difficulties with the maintenance of tens of references that need to be updated once a new SP is released.
Having in mind the above, we tried to make a compromise - put all smaller controls in common assemblies (this reduces the number of references to maintain) while the large controls are in separate assemblies (this reduce the bulk when you don't need them). Unfortunately the scenarios are countless and we cannot provide the best configuration of controls in our assemblies for everyone.
All the best,
Valeri Hristov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
Trude
Top achievements
Rank 2
Rank 2
answered on 15 Feb 2010, 02:23 PM
Previously our silverlight application was embedded in a plain .aspx page - login/authentication was done from inside the application with WCF RIA authentication - very easy. The login was very pretty and all, but the application could be downloaded by everyone. Now we have a asp.net login-control (ssl required) that redirects the user to the application on a succesful login. Obvious as it may seem I think this is the single most important step to protect your application from prying eyes. When I was learning Silverlight and WCF RIA services (watching tutorials and reading blogs/forums) it didn't cross my mind and there was very little focus on it.
As for obfuscation I will soon be trying out this product (several people at silverlight.net recommends it):
http://www.ssware.com/cryptoobfuscator/obfuscator-net.htm
As for obfuscation I will soon be trying out this product (several people at silverlight.net recommends it):
http://www.ssware.com/cryptoobfuscator/obfuscator-net.htm
0
Ben Hayat
Top achievements
Rank 2
Rank 2
answered on 17 Feb 2010, 01:11 PM
Hi Valeri;
As I said before, your points are well taken and valid, but here is my question and it's a question that keeps popping in my head every time I hear the definition of MEF and perhaps Prism.
Can MEF with it's plugin extensibility architecture be any help or value to third party vendors like yourself, where one control is dependency on another and the other one has dependency on another and so on? Creating a chain of dependencies that require several assemblies to be available at all time to have proper design and runtime resolution. Will MEF help? If yes, does it mean that the vendors have to change their architecture according to MEF system in order to take advantage? If yes, will that mean the users of your controls (which are us, the developers) have to also change our way of development to the same structure?
Thanks!
As I said before, your points are well taken and valid, but here is my question and it's a question that keeps popping in my head every time I hear the definition of MEF and perhaps Prism.
Can MEF with it's plugin extensibility architecture be any help or value to third party vendors like yourself, where one control is dependency on another and the other one has dependency on another and so on? Creating a chain of dependencies that require several assemblies to be available at all time to have proper design and runtime resolution. Will MEF help? If yes, does it mean that the vendors have to change their architecture according to MEF system in order to take advantage? If yes, will that mean the users of your controls (which are us, the developers) have to also change our way of development to the same structure?
Thanks!
0
Hello Ben,
On a first glance, I don't think that MEF could help us (a lot) with the control dependencies at this moment, mainly because we want to use our controls in XAML (in Scheduler - ComboBoxes, Calendars, etc.). Sometimes those controls have custom themes (we try to minimize that, though) which additionaly increases the complexity of the task...
It sounds like a good idea to use MEF in the control assemblies, though. Perhaps if Silverlight 1.1 was released yesterday and it contained the features of Silverlight 4 now, and I was designing our libraries from scratch I would definitely try to compose the bigger controls with MEF :)
Best wishes,
Valeri Hristov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
On a first glance, I don't think that MEF could help us (a lot) with the control dependencies at this moment, mainly because we want to use our controls in XAML (in Scheduler - ComboBoxes, Calendars, etc.). Sometimes those controls have custom themes (we try to minimize that, though) which additionaly increases the complexity of the task...
It sounds like a good idea to use MEF in the control assemblies, though. Perhaps if Silverlight 1.1 was released yesterday and it contained the features of Silverlight 4 now, and I was designing our libraries from scratch I would definitely try to compose the bigger controls with MEF :)
Best wishes,
Valeri Hristov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
Ben Hayat
Top achievements
Rank 2
Rank 2
answered on 17 Feb 2010, 02:11 PM
It sounds like a good idea to use MEF in the control assemblies, though.
Perhaps if Silverlight 1.1 was released yesterday and it contained the
features of Silverlight 4 now, and I was designing our libraries from
scratch I would definitely try to compose the bigger controls with MEF
:)
That's what I trying to say... Seems like starting all over! which is impossible, since the train has already left the station with passengers on board :-)
So, I think MEF will become more of reality for application developers like us than component developers (especially the ones with a large existing code). I'm trying to get my head around MEF and Prism4 (when that gets done) to see how to build modular apps for SL.
I thank you for the reply!
That's what I trying to say... Seems like starting all over! which is impossible, since the train has already left the station with passengers on board :-)
So, I think MEF will become more of reality for application developers like us than component developers (especially the ones with a large existing code). I'm trying to get my head around MEF and Prism4 (when that gets done) to see how to build modular apps for SL.
I thank you for the reply!
0
David Stanfield
Top achievements
Rank 1
Rank 1
answered on 22 Feb 2010, 05:43 PM
I've been pleased with the success I've had using MEF to dynamically load XAP files at runtime. Using this technique I can lazy-load assemblies only as the user needs them.
I have also seen a significant increase in the startup time of my application. This is not only better for the user, but for me as a developer as well. I must start the app (via Ctrl+F5 or F5) a hundred times a day. Having it pop up on my screen (so I can see if my code changes did what I want them to has saved me a lot of dead time during my day.
There's nothing worse than sitting there waiting for the app to open in the browser, and I've found that the bigger a project gets, the slower the startup time (naturally) gets.
David
I have also seen a significant increase in the startup time of my application. This is not only better for the user, but for me as a developer as well. I must start the app (via Ctrl+F5 or F5) a hundred times a day. Having it pop up on my screen (so I can see if my code changes did what I want them to has saved me a lot of dead time during my day.
There's nothing worse than sitting there waiting for the app to open in the browser, and I've found that the bigger a project gets, the slower the startup time (naturally) gets.
David