Wolfgang wrote: Can you please tell me how to install SLP Code Protector an .NET4/VS2010 based system.
Firstly, our apologies that you've encountered this failure scenario and have obviously spent significant time attempting to circumvent these issues. We've had VS2010 support since March (there was a short term pertaining to a chance between the RC and RTM editions which is covered elsewhere on this forum) with no installer issues of this nature reported. While the 3.0.1912 release from recent days adds support for targetting assemblies that require .NET 4.0 (previous releases limited the target framework to 3.5SP1 or lower), the Slps.Runtime.Configuration.exe tool itself is unchanged since March.
Thanks for the detailed information you provided - if this was on SO, there'd be many upvotes on the question :P
Wolfgang wrote: After that I managed to successfully install it by calling
Slps.Runtime.Configuration.exe /msbuildtargets installAuto;platform=x86;Version=v4.0
I admire your ingenuity in working this out! This command hooks up the SLPS_PROTECT driven inline protection. Unfortunately the intialization of the license store is a separate operation, initiated by issuing the following command:
Slps.Runtime.Configuration.exe /install
The reason they are separate commands is that one may wish to intialize a license store on a machine that is not being used for development (see the Xcopy deploy scenarios in http://support.inishtech.com/kb7)
Wolfgang wrote: But still SLP Code Protector complains that the Licensing storage is not configured, e.g. when calling Microsoft.Licensing.ProtectCmd.exe I get the following output
InishTech(R) SLP Code Protector Command-line Utility Version 3.0.1912.27 on 32-bit .NET 4.0.30319.1
Copyright (C) 2010 Inish Technology Ventures Limited. All rights reserved.
InishTech SLP Code Protector installation issue:
Licensing storage is not configured. Please ensure the software has been installed correctly.
The above banner shows that execution is correctly being bound to 4.0. This is expected as Microsoft.Licensing.ProtectGUI (Code Protector on the start menu) and Microsoft.Licensing.ProtectCmd both have specific config files that say "we've been tested with 4.0, so use it in preference to 2.0 if you have it available". Unfortunately this is not the case for Slps.Runtime.Configuration.exe. It's not clear at this stage how this potential inconsistency didnt come to light during our internal testing and beta testing of our CLR 4.0 support - both our development team and a number of consumers will, like many developers have side by side VS2008 and VS2010, CLR2.0 and 4.0.
Wolfgang wrote: InishTech(R) SLP Services Runtime Configuration Utility Version 3.0.1912.27 on 32-bit .NET 2.0.50727.3615
Copyright (C) 2010 Inish Technology Ventures Limited. All rights reserved.
Invoking SLPS installation step ...
There has been a problem configuring SLPS Runtime services, full details:-
System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize ---> System.Configuration.ConfigurationErrorsException: Unrecognized configuration sect
ion system.serviceModel.
This suggests that the tool has loaded under .NET 2.0, but for some reason the patching is such that the framework can't process it's own config files despite the fact that the .3615 suggests you do have 3.5 SP1 (which is a prereq for the Code Protector SDK which is checked by the installer). We'll attempt a repro with the aim of resolving this for the next Code Protector release.
In the meantime, the following workarounds approaches would allow one to circumvent the issue:
1) remove .NET 2.0+3.5 - obviously an agressive thing to do - lots of system components and third party apps may depend on it
2) force Slps.Runtime.Configuration to load under .NET 4.0 where available by putting in an app.config file for it with a SupportedRuntime 4.0 element first (e.g., you could take a copy of Microsoft.Licensing.ProtectCmd.exe.config and name it Slps.Runtime.Configuration.exe.config). Obviously this is hard to achieve as the tool is running the control of the MSI installer.
While, you may be able to cause a SDK install to complete successfully armed with the above information - it's not a route I'd be holding up as ideal.
As a result, I suspect the best route for you given you have a box that you can successfully install on (and the demonstrated desire to remedy the situation via commandline trickery :D) is to do a manual 'install':
1) install on one box
2) copy all the files over to the other box
3) run Slps.Runtime.Configuration.exe /msbuildtargets installAuto;platform=x86;Version=v4.0
4) run Slps.Runtime.Configuration.exe /install
5) create a start menu shortcut to Microsoft.Licensing.ProtectGUI.exe entitled SLP Code Protector
NB while the above represents a sequence very similar to those carried out by the installer itself, please do not consider the above to be the official documentation - this is very much subject to change and oru aim is for the installer to Just Work as it should in all cases.
Note that this is the only instance of this issue, or anything of this nature that's been reported. We dont expect this to be a widespread condition -- there are many other customers with this mix.
We'll aim to resolve this more completely ASAP by:
a) attempting to repro the issue in order to understand exactly what combination of .NET CLRs and Visual Studio editions trigger the behavior you've triggered
b) issuing a patch edition of Code Protector in due course with a .exe.config that prevents this from happening by nominating supportedRuntimes of 4.0 and 2.0 in that order in the very near future
We'll post here when an update is available (unfortunately next Monday is a Bank Holiday in Ireland which may delay matters briefly).
Our apologies once again for the inconvenience; Please let us know if you manage to successfully apply the above workaround(s).
Regards,
Ruben.