|
|
|
Rank: Member
Groups: Registered
Joined: 10/20/2010
Posts: 8
|
Hi,
We are using licensed .net 4 wpf rapidspell. Currently when running versions of our application that have been built on our build servers the users are prompted for a licence key.
What we have already done:
1) Using visual studio 2010 as the user that the build is performed as, licenced the RapidSpellAsYouType component on the build machines.
2) Using the Component-Register exe entered the registration key.
what happens:
The component no longer complains when you open the xaml page within visual studio on the build machines.
but...
When the application is built automatically, using msbuild, the license information appears to get lost and the users get the prompt when running the software.
Please note that the builds are created using msbuild, not visual studio.
Any help is appreciated.
Cheers.
|
|
|
|
Rank: Advanced Member
Groups: Administrators, Registered
Joined: 8/13/2004
Posts: 2,669
Location: Canada
|
Hi, when you used Component-Register exe was it on the build server? Also, what user account does your msbuild process run under (i.e. is it a Windows Service)? You have to run Component-Register exe as the same user as your build process runs under. Eg. http://keyoti.com/kb/Def...ew&questId=222&catId=64
the article is specifically about TFS but generally explains how to register under a different user account. Best Jim -your feedback is helpful to other users, thank you!Evaluation Downloads - http://keyoti.com/products-your feedback is helpful to other users, thank you!
|
|
|
|
Rank: Member
Groups: Registered
Joined: 10/20/2010
Posts: 8
|
Hi Jim,
All the registration within Visual Studio and using the Component-register were done on the build machines, logged in as the user that the CI service (in our case Hudson/Jenkins CI) runs as.
This was done via an RPD session as the machines are headless. The CI instance runs as a windows service, and has domain admin rights, log on locally and service rights.
The only thing I can really think that might be causing this is the fact that the build servers get a fresh copy of all the code out of SVN for each build, hence the license.licx will be from the repository each time.
Are there any differences in the way licensing works between msbuild and visual studio?
Cheers
|
|
|
|
Rank: Advanced Member
Groups: Administrators, Registered
Joined: 8/13/2004
Posts: 2,669
Location: Canada
|
Hmmm, no the licensing is the same with msbuild. Some tips; 1. we store the license key in the user's IsolateStorage, so it should be in a folder named something like this (the random stuff is probably unique per machine) C:\Users\<USERNAME>\AppData\Local\IsolatedStorage\kdtjoavo.skw\rwuhqell.us1\StrongName.0rimevyjygl12xedjsqwwk4ebhj2x2ub\AssemFiles in a file named Keyoti.RapidSpell.WPF Perhaps verify that it's there. 2. Renaming the EXE after it's built will kill the licenses inside - are you doing that? HTH Jim -your feedback is helpful to other users, thank you!Evaluation Downloads - http://keyoti.com/products-your feedback is helpful to other users, thank you!
|
|
|
|
Rank: Member
Groups: Registered
Joined: 10/20/2010
Posts: 8
|
Hi Jim, The build machines are win2003 server, not that it should make any difference. the Keyoti.RapidSpell.WPF file exists in the build users isolated storage and contains our licence key, We do not rename the exe as part of our build process, however we do generate 'custom' installers, which have the build number and configuration in their filename, But once they are installed the exe file is the startup assemblies name (i.e. <AssemblyName>.exe) It appears that if we generate the msi manually within visual studio on the build machine the licence file is included correctly, however, during the automated build the licence file doesn't.
|
|
|
|
Rank: Advanced Member
Groups: Administrators, Registered
Joined: 8/13/2004
Posts: 2,669
Location: Canada
|
So the EXE is renamed during the process, but put back to normal at the end... I just tested doing that and it should be fine, provided the name is exactly what it was in the first place. If you copy the EXE (named correctly) and DLLs to your local machine, before they go into the MSI, does it work? I suppose it is going to work since you said it worked when you manually made the MSI... Does the automated MSI creation process do anything to the EXE? Jim -your feedback is helpful to other users, thank you!Evaluation Downloads - http://keyoti.com/products-your feedback is helpful to other users, thank you!
|
|
|
|
Rank: Member
Groups: Registered
Joined: 10/20/2010
Posts: 8
|
Hi,
The exe is not renamed in any way during our automated build process, it is the MSI that is 'named' (but not renamed!).
The automated process of creating the MSI simply calls the Visual Studio IDE from the command line, and hence doesn't do anything special with the msi at all.
|
|
|
|
Rank: Advanced Member
Groups: Administrators, Registered
Joined: 8/13/2004
Posts: 2,669
Location: Canada
|
Sorry I think I misunderstood what you wrote earlier. Ok, so is the following true; A. Run the regular automated build process - the MSI that's created will install an EXE that has our nag screen. In which case; if you copy the EXE from the build machine to the install machine, does it still show the nag? Point being, is the EXE wrong, or is it the install process that's wrong? B. Run the build process, but manually build the MSI, using the same setup project - the MSI that's created will install an EXE that does not have our nag screen. Both of those are correct? Could you email me both resulting EXEs (no DLLs or anything else) from the 2 situations above please so that I can compare them? You can email me via support at keyoti.com and maybe best to upload the EXEs to http://mediafire.com instead of attaching. Think you'd agree that it seems odd that running the MSI project automatically instead of using VS would make any difference. Jim -your feedback is helpful to other users, thank you!Evaluation Downloads - http://keyoti.com/products-your feedback is helpful to other users, thank you!
|
|
|
