Progress® Telerik® UI for WPF Feedback Portal
Back to Feed
Request a Feature Report a Bug
Duplicated
Last Updated: 28 Jul 2023 11:11 by Richard
Richard
Created on: 12 Jul 2023 10:29
Category: UI for WPF
Type: Feature Request
0
Move file protection into a separate DLL to avoid building from source...

Here's an idea for you, one which I haven't fully thought through but which I will post here in case it proves useful.

For my use case we am required to build the Telerik UI for WPF binaries from the source code. This is because we offer our product as a trial version which requires the source files to be protected.

Building the source takes a bit of time whenever there is a new version and we have to remember to copy and replace the modified source protection files before we build the binaries.

My suggestion would be to move the file protection code into a single separate class library (DLL) and provide the source code that can be modified by the end user and rebuilt into the file protection DLL.

Then rather than having to rebuild the entire source code from scratch whenever there is a new version, we could just use the installer to install the new binaries and just replace the FileProtection.dll file.

That way when there is a new version of UI for WPF (or whatever product) we could quickly update to it and then when we build our product installer we just copy the modified FileProtection.dll to be bundled alongside the Telerik binaries.

As I said I haven't thought this through all the way and there may be excellent reasons why you are unable to do this, but I thought I'd share the idea.

 

HTH Richard

Duplicated
This item is a duplicate of an already existing item. You can find the original item here:
Common: Improve the Telerik UI for WPF assembly protection mechanism
5 comments
Richard
Posted on: 28 Jul 2023 11:11
Thanks Martin, much appreciated.
ADMIN
Martin Ivanov
Posted on: 27 Jul 2023 19:42

Hello Richard,

I am following up my last reply, to let you know that we have further discussed this and we have logged a new feature request on the dlls protection mechanism topic. I am adding this feature request as duplicated item to the other item in order to link them.

Regards,
Martin Ivanov
Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.

ADMIN
Martin Ivanov
Posted on: 18 Jul 2023 12:18

Hello Richard,

Thank you for sharing your thoughts again.

The idea with the FileProtection.dll is not bad, but it has two issues related to the current state of the product. First, bringing an additional assembly will cause a major breaking change to absolutely all customers using Telerik UI for WPF. That is because the Telerik.Windows.Controls.dll will start to depend on a new assembly and everyone should reference it in their projects, whether they should protect the dlls or not. Second, the Telerik assemblies are signed and the new dll should need to be signed as well. This brings the problem that even if the FileProtection.dll gets rebuild, its public key generated during build won't match the public key of the other Telerik dlls.

I believe that your second idea with the service that generates the protected dlls by only providing the application name is very good. I will forward this to the responsible people so that can be discussed further, but at this point we don't have plans to introduce such service.

At this point, we want to research the idea with the tool that should allow easy build of the dlls, so we will invest some time there.

I am going to decline this feature request now, because we can't implement this with our current infrastructure, but feel free to write any other feedback you have here, or in a new item in the feedback portal, if you have other ideas.

Regards,
Martin Ivanov
Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.

Richard
Posted on: 12 Jul 2023 13:54

Thanks Martin,

I believe my suggestion would still offer the same level of file protection without having to rebuild all of the DLLs.

If you take the file protection code and move it into a single separate DLL (say FileProtection.dll), for example the Telerik.Windows.Controls.dll would depend on FileProtection.dll and wouldn't function without it if it wasn't present.

So if the user copied Telerik.Windows.Controls.dll to another project they would also need to copy FileProtection.dll.

FileProtection.dll would be built from source code with the application name embedded in it, which would still tie the dlls to the named application.

It's just that the dependency on file protection would be extracted to a single DLL and not duplicated code in every Telerik DLL that requires protection. The Telerik DLLs would no longer need to be built from the source code and only the FileProtection.dll would need to be customised and rebuilt from source.

PS. FileProtection.dll would be a bad choice of name, for security it'd be better to obfuscate the name and call it Telerik.Environment.dll or something so it's not obvious what the intent of the protection DLL is.

 

The idea of a build tool is good, definitely better than the current situation which is we have to follow a Word document that we have written that has our notes on how to do a manual build. It'd also help with the current situation where the build steps have changed.

 

A further idea related to my suggestion of having a single file protection DLL would be to allow registered users on your website to register an application name, and then have the file protection dll auto generated by your web server which we could then download. We wouldn't have to build anything from source and you would have full control over which applications are registered to use Telerik components in a demo environment.

 

Best Regards - Richard

 

 

ADMIN
Martin Ivanov
Posted on: 12 Jul 2023 12:38

Hi Richard,

Thank you for sharing your idea. Any feedback is welcome.

One of the main purposes for protecting the Telerik assemblies is to avoid the end user of your application to use them. When you deploy an application, a common scenario is that you provide also any third party dlls (like Telerik UI for WPF) used in the WPF application along with the .exe and the other files. If I am the user of such application, I can access the Telerik dlls from the installation folder of the application and use them without permission in order to create my own application. The protection process ensures that the Telerik.Windows.Controls.dll is "corrupted" with the custom application name and only one application can use this dll. Whenever you reference the Telerik assembly in another WPF project, an annoying popup appears every 30 seconds. The other Telerik dlls doesn't need to get protected because they all rely on Telerik.Windows.Controls.dll and cannot be used without it.

If we move the protection into another assembly, the user of your application can get the Telerik.Windows.Controls.dll and use it without permission.

Here is another idea that we can explore. Instead of going through the build instructions and edit, and execute files from different directories in a specific order, what do you think about the idea to have a tool that does this for you? What I imagine is a desktop application that allows you to enter paths to the source code directories of UI for WPF and the DPL components, then enter .NET version, Xaml or NoXaml version, and application name. Clicking a button will edit and execute all needed files in the required order and will generate all needed Telerik dlls.

Regards,
Martin Ivanov
Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.

Create an account Log In
View
Type
Status
Category