We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy.
Apologies if this is in the wrong forum. It's really about licencing rather than a specific control but I couldn't see a better place for it and the sfDataGrid is the control we've used most.
My product has the concept of being to run analyses which are based on algorithms. I will ship some pre-rolled algorithms but would also like customers to be able to develop their own. For that reason I have based the algorithms on the MEF framework.
The Algorithms contain visual components (to allow the user to configure the algorithm and to display the results of running an analysis) and I have used your controls in these visible components.
I would expect the existing licence to cover the pre-rolled algorithms we supply but not ones that a user developed. A user would either have to use the standard WPF components or buy a licence to use yours.
In my initial implementation I included an algorithms plugin project in my main solution. This works fine, the register licence in app.xaml seems to cover all the built projects. However, I really want to move that project into its own separate solution as the main solution shouldn't depend on the plugin project (that's really the point of plugins).
When I did this I got a message when showing a visual component that the "project had been built using a trial version". That's fair enough as nothing in the plugin project was now registering the licence and I guess the licence validation is done at build, rather than run time. I tried adding a call to RegisterLicense in the constructor of each plugin but that then gave a message saying it was built with an invalid licence with a link where I could acquire a new licence code. I tried that and it works but I assume this is a 30 day trial licence.
So I guess my question is, should a licence cover multiple VS solutions intended to work together as a single product? If not, how does that relate to plug in architectures spread across multiple solutions?
It's not the end of the world if your licence does not cover this, I'll simply move the plug in project back into the main solution. However, this feels like I'd be abandoning best programming practice.
I'm afraid the main solution is much to big to attach here but I can probably mock up a demo if it would be useful
Any advice would be appreciated.
Hi Declan Hillier,
The license registration should be done in each project where our control is
used.
Syncfusion license keys are only version and product-specific. Also, “the
generated license key is just a string that needs to be registered before
any Syncfusion control is initiated”.
You can use this license key in multiple projects, but make sure you are using the same version Syncfusion nuget packages in all your projects or deployed application.
We have generated the WPF license key v20.4.0.42 from your account.
|
ODc4OTAyQDMyMzAyZTM0MmUzMGlTU0NSUHBnU053RHFmcEVWdWdvdkNKbTJQTDhodU81QVovUEJDc1I2NEk9 |
To know about registering license key,
https://help.syncfusion.com/wpf/licensing/how-to-register-in-an-application
Find below the knowledge base article to know about which
version license key should use in application,
https://www.syncfusion.com/kb/8951/which-version-syncfusion-license-key-should-i-use-in-my-application
Regards,
Vijayarasan S
If this post is helpful, please consider Accepting it as the solution so that
other members can locate it more quickly.
Thank you for the response.
I won't get to try breaking it out again until next week but I'm willing to bet I used a different version from NuGet in the plug in project. I'm willing to bet you brought out a new version in between my original solution and the plug in one, so the latter will have used a more up to date version. I will try it again and post back the results.
Thanks as always. The support I've recieved from this forum has been excellent.
Thanks for the update, Declan. We will wait to hear from you. Please test at your end. Also, let us know if you require any further assistance on this. We will be happy to assist you.
Finally got round to trying this and can confirm that updating the plug ins to the latest version and then claiming a new licence has everything working perfectly. Thanks for your help.
Contrary to what I said above I didn't need to register the licence in the constructors of the plugins. So, presumably, a plug in can use SF components as long as they're covered by the licence of the consuming solution. This does raise a question:-
If the plug in was developed with an older version of the software, will a licence for a more recent version still cover it? I can imagine a scenario where, for example, a plug in gets written in version 20.4 and gets shipped to a customer. Then we upgrade the SF version of the main project to version 20.5 and claim a new licence. Ideally I wouldn't want to have to upgrade the plugin.
(it won't be the end of the world if we have to upgrade the plug in. It's just a bit of extra admin I'd rather avoid if possible)
Declan, if you are upgrading our components to major Volume releases, say from v20.4 to v20.5, then you should upgrade the license key also.
You need to update the license key in your project for every major volume release upgrade only. Syncfusion will have only four major releases (Volume releases) in a year. So, you might have needed to change the license key four times in a year.
Upgrading to Volume release
If you are using the application with Syncfusion version 20.3.0.* and trying to upgrade to our next volume release version 20.4.0.*, you should generate the license key for v20.4.0.* and update the key in your application.
For example, if you are using v20.3.0.36 and trying to upgrade to next volume release v20.4.0.47 you need to regenerate the licensing key for v20.4.0.47 from our website and update the license key in your application.
Upgrading to Service Pack\NuGet release
Our Volume release license key (20.3.0.*) can be applied to its service pack\nuget releases.
If you are using the application from Syncfusion version 20.3.0.* and trying to upgrade to its service pack\nuget release in same volume release, there is no need to regenerate the license key again.
For example, if you are using v20.4.0.36 and trying to upgrade to its service pack\nuget release in same volume release v20.4.0.41 or v20.4.0.42 there is no need to regenerate and apply the license key again for service pack\nuget releases.
Refer to the below KB article to know about which version license key should use in application,
https://www.syncfusion.com/kb/8951/which-version-syncfusion-license-key-should-i-use-in-my-application
Our license keys were version and product specific. So, if you would like to frequently upgrade to our components from nuget.org, then to remove the license warning, you should register the Syncfusion license key in your application for your required version.
If you don’t wish to register the license key in your application, you could download the licensed installer from your account and use that in your application. In this case, no license message will be displayed. Find below the details to download and install the licensed version of our installer,
https://help.syncfusion.com/common/essential-studio/installation/web-installer/how-to-download#download-the-license-version
Installation steps: https://help.syncfusion.com/common/essential-studio/installation/web-installer/how-to-install
Let us know if you have any queries on this.
Hi Jeyaseelan
Thank you for the information. That's great.
My issue is to do with plug in components. Because they're not part of the main solution you can't register the licence in App.xaml.cs (there is no App.xaml.cs) so it gets covered by the registration of the application that consumes the plugin.
I've done a bit of experimenting and it seems like the plug in does need to use the same version as the consuming application. That's a very mild irritant because it means I need to update the plugin project alongside the consuming solution but it's honestly no big deal, just a tiny bit of extra admin to remember when releasing. Overall I'm vey happy with the way it's working.
Thanks, as always, for your help.
We are happy that the reported problem has been resolved. Find below the response for your queries.
Q1) My issue is to do with plug in components. Because they're not part of the main solution you can't register the licence in App.xaml.cs (there is no App.xaml.cs) so it gets covered by the registration of the application that consumes the plugin.
A1) There is no need to be concerned if your plugin project lacks an App.xaml.cs file. The generated license key is simply a string that must be registered before any Syncfusion control can be used.
Q2) I've done a bit of experimenting and it seems like the plug in does need to use the same version as the consuming application. That's a very mild irritant because it means I need to update the plugin project alongside the consuming solution but it's honestly no big deal, just a tiny bit of extra admin to remember when releasing. Overall I'm vey happy with the way it's working.
A2) Yes, the same version license keys should be used. If you are upgraded the project, you must use the upgraded version license key in your projects plugin too
Please, ensure that all the referenced Syncfusion assemblies\NuGet packages are all on the same version as license key’s version in your project.
Please let us know if you have any further questions.
