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. Image for the cookie policy date


I (and other registered users here at my company) have been struggling with the Syncfusion licensing/distribution model. And so I am going to rant a bit here... sorry. If I understand correctly, in order to distribute a build that contains Syncfusion controls, there must be a licenses.licx file that contains entries for each Syncfusion control used present in each assembly. The file is created via some magical process whenever we drop a Syncfusion control on a form while in design mode. Once created, we supposedly can get the .licx file to update by "touching" the Syncfusion controls then saving (note that this does not work reliably for me). Another alternative is to add a dummy form to a project, drop the controls we want licensed for distribution onto that form, save the project, then delete that dummy form (this works reliably, I think). If I understand correctly, each machine must generate it''s own licenses.licx files. So we cannot, for instance, generate a proper set and then put them away in our version control system so that everyone can be ensured to be working from the same page. We have some problems with this approach. 1. We want to be able to generate builds from a dedicated "build" machine. That machine might only have a link-license on it. If I make a change on my machine that requires an update to the licx file (adding a new Syncfusion control or changing versions), then I need to touch the licenses.licx file on my machine to get my distributed builds to work. But how can I get the licenses.licx files on the build machine updated to match mine? 2. As implemented, the existing process seems to us to be very fragile. It often doesn''t work and we wind up having to post Direct-Trac questions about how to get things working again. This makes us feel stupid. I may actually be stupid, but my co-workers are pretty bright and they don''t like being made to feel stupid. 3. I just downloaded and upgraded to the latest version (3.x.x.x) and discovered that I have to manually go into my projects and fix-up all the licenses.licx files to get my distributables to work. This is a real problem because I upgraded mostly to find out if the new code fixes some odd behavior we''re seeing in the GridListControl (a story for another day). So I will probably need to shift back to building for the latest 2.x.x.x build until such time as we are set to switch over all our clients to using the 3.x.x.x DLLs (some of those clients have IT departments that get mad at us when we make them install new DLLs willy-nilly). 4. I have lots of guesses as to ways to make some things easier for us. For instance, I am thinking that perhaps I could use lc.exe and force it to run every time any of us (or the build machine) builds. And I am thinking that for all I know, I can include the licenses for all the versions of the controls I might use in my licenses.licx file so that switching between versions will be relatively painless. I also am wondering if a licenses.licx file generated on my machine will work on everyone elses machine. But the problem is that I don''t know the answer to these questions because there is no detailed documentation on the licensing/distribution model. There''s some tidbits that read more like workarounds (which is where I got the idea of using a dummy form to update the licx files). They are nice, but they are not enough. Here''s a suggestion or two: 1. Get rid of the licenses.licx requirement entirely. I am not terribly well versed in the whole licenses.licx concept, but I''ve seen enough to know it ain''t working out to well. 2a. Since I''m pretty sure you won''t agree to (1), then write us a utility that allows even idiots like myself to manage the licenses.licx files for a given VS solution. Preferrably a GUI-based utility so we don''t have to remember arcane command-line arguments. 2b. Supply another utility with new versions that just goes out and finds all licenses.licx files with Syncfusion controls and adds the new version of the controls to the licx files for us so we don''t have to do it manually. 2c. Provide us with a detailed document that tells us, in depth, how all the various moving parts of the licensing/distrubition model work so that we can craft our build systems and distribution systems with some idea of what will and won''t work (for example, how does the application ever "register" the existence of the licenses.licx file). Thanks. Sorry for ranting. Andy

9 Replies

AD Administrator Syncfusion Team January 25, 2005 07:45 PM UTC

This is probably more appropriate in the General forum. Just a couple of comments. I''ll let others look\respond to your rant. The license model is not a Syncfusion model. It is a .NET Framework model. We have chosen to use it, but it is part of the framework. My other comment is the license.licx file is strictly a text file. You can look at it in any text editor. You can put it in VSS or anywhere else you want it. It does have to be included in your exe/dll project as an embedded resource and your project has to be built on a system that has a licensed version of syncfusion installed. But it should be the same as any other project file as far as managing it in some source safe system.

AD Administrator Syncfusion Team January 25, 2005 08:25 PM UTC

We are seriously considering changing this system. We are currently evaluating other licensing options and will decide on this before the end of the week. We will send you a private update on this by the end of the week.

AD Administrator Syncfusion Team January 25, 2005 08:54 PM UTC

Clay, Clay, I should mention before I go on that I think the Syncfusion product is great and that the tech support you and others have provided here has been truly outstanding - the best of any 3rd party product I''ve owned. I should''ve said that prior to my rant at the top of this thread. I sort of understood that the licenses.licx thing was a .net invention. But I also know that we use another 3rd party control (for reporting) that does not require any special effort on our part to manage licensing and distribution. Obviously, since that is simplier for us than any scheme involving the licenses.licx approach, we''d prefer not to have to deal with licx files at all. I realize that the licx files are text files and that we can stow them away in version control. But I checked the PublicKeyToken values in the licx files on my machine vs. other''s machines here at my company. The ones on my machine are all the same. The ones on others machines are different from mine. So I''ve made the (quite possibly incorrect) assumption that my licx files will not work correctly if used on others machines. If my assumption is incorrect and my licx files will work just fine on others machines, then we can maintain a "golden" set of licx files for our projects that incorporate Syncfusion products. Still, the need for utility to ease upgrades (I know someone else posted a thread about this recently as well) would make sense here. Having said that, if you can verify a couple of details for me, I can write my own utility to manage licx files: 1. How can I generate the proper entries for the licx files w/out having to even open a VS solution or project? 2. Is there any particular significance to the PublicKeyToken value in the licx file? 3. Will my public key tokens work on someone else''s machine (assuming the machine has a valid license on it). Thanks, Andy

AD Administrator Syncfusion Team January 25, 2005 09:38 PM UTC

1) You include a line for each syncfusion control your project uses. The line includes the fully qualified name, the assembly name, the version, and the public key token. Open up any license.licx file and mimic it, just changing the control name, assembly name and version number as needed. 2) There is only one syncfusion public key for our library dlls. 3d67ed1f87d44c89 (But it does look like the Core.DLL does has a different key, 632609b4d040f6b4 but you would not use this in a licensed manner). These keys should not change. I may be wrong, but as far as I know this 3d67ed1f87d44c89 key is the only public key we haved used for the 2.0 and 3.0 licensing support. The only reason I can think of for you to have a different public key is if you are creating and building custom versions of our DLLs. Then you must sign them and use your own public-private key pair generated using the sn.exe utility. 3) There is only one Syncfusion library public key. 3d67ed1f87d44c89

AD Administrator Syncfusion Team January 26, 2005 01:09 AM UTC

Clay, All my public keys match the one you say I should have. But my coworker has an entirely different one. And he does not have the source-code to build a custom version of the code. Strange. We will investigate that in the morning. In any event, your answers are providing me with what looks like some simplification in the deployment approach. I will create some "master" licx files for our projects and will ensure they are added properly to the projects and will put them away in our version control system so that everyone is using the same files. By the way, there''s nothing wrong with having the licenses for different versions of the same controls in the licx file at the same time, right? I hope. Thanks for the info. I feel like I''m starting to understand this stuff. Can I suggest that the informative details from this thread be posted in the knowledge-base and in the online help that integrates with VS.NET as well? Thanks again, Andy

RM Randy Magruder January 31, 2005 12:41 AM UTC

Anything that you SyncFusion guys do to address this, could you please do it in a way that does not ASSUME the presence of VS.NET? I''m using Delphi 2005''s C# Builder personality and it doesn''t seem to be generating the license file properly when I use the UI. I found a licenses.licx in one of my other directories, but have no idea what magic I performed to make it get there. Thanks, Randy

AD Administrator Syncfusion Team January 31, 2005 06:58 AM UTC

Our licensing requirements are under review at this time by our management so there may be some changes coming. I do not know when this might come about, if ever. The .licx file is just a text file. It is usually automatically generated for you at design-time by Visual Studio. If you are not using the Visual Studio designer, and your development environment does not create .NET Framework licx files for you, then you will have to create this file with a text editor and manually include it in your project.

AD Administrator Syncfusion Team January 31, 2005 11:00 PM UTC

I thought you *were* the management there. ;-) In an effort to ease the problems were having with the licx files, I created files that all contained the same six entries, an entry for GridControl, GridDataBoundGrid and GridListControl for both 2.x and 3.x versions. I then rebuilt a 3010-based version of our app and then sent off a build to my boss to test. He has a link license (2.x) installed, but no 3010 license. He got the licensing error exception. So I built a 2.x-based version of the same code, sent it over and he was able to run that without complaint. I''m attaching a zip file that contains the .licx file. I believe it''s properly formatted but it will not with to distribute 3010-based code. Can you please check the licx file and verify that it''s properly formatted? If so, can you pass along this new .licx gotcha to whoever it is there that is reviewing the licensing approach? Also, can you think of anything else I might be doing wrong that is causing that build from my machine to not run on another''s machine? Thanks, Andy licx_8790.zip

AD Administrator Syncfusion Team February 1, 2005 12:30 PM UTC

I checked with the license engineer here, and I think the best you would be able to do is to have two licx files, one for 2109 and one for 3010.

Live Chat Icon For mobile
Up arrow icon