SLP Code Protector Discussion For conversations regarding usage of Code Protector and issues pertaining to SVM protected code.
InishTech Support Forums > SLP Code Protector Discussion > "Failed to load type" exception at runtime on .NET 4 despite targetting 4.0 when protecting on 4.5+ Login to add this as a favourite.
User avatar
Member
Member
bsar - 11/16/2013 2:37:26 AM
   
"Failed to load type" exception at runtime on .NET 4 despite targetting 4.0 when protecting on 4.5+
I am using SLP code protector version  3.2.1944.79. I have vs2013 installed and a project targetting .NET4. The system running SLP code protector (it is the same system as vs2013) has .NET4.5.1 installed.

If the target computer does not have .NET4.5.1 installed, protected methods fail to execute (unprotected assembly runs fine). I assume that the problem has to do with the now hidden UI field <TargetCLRVersion>. I checked the SLMCfg and lists <TargetCLRVersion>Standard</TargetCLRVersion> not sure how this resolves in comparison to previous SLP versions. I have read old posts about that UI field, but obviously this does not apply any more.

Of course we can install 4.5.1 on target machines (as a workaroud) but this is not optimal, since we do not really target .NET4.5.1, and this seems to be a side-effect of the SLP-clr binding on protection. I tried to manually edit the cfg file and use v2.0.50727, (as was the old suggestion) but a) this is ovewritten by the SLP b) even if I call the command line tool with a specific clr version it seems to have no effect.

Am I missing something on the above assumptions? Is there any other solution?


User avatar
InishTech Dev
InishTech Dev
RBartelink - 11/17/2013 1:19:15 AM
   
RE:Protected Method fails

Hi, thanks for taking the time to report your issue.

Your inferences are largely correct. The TargetClrVersion (at one point, the choices were 1.1 and 2.0) field is now mapped to Target Runtime Variant in the UI at present 

At present, the key choices are:

Standard. This requires .NET 2.0 raw (i.e. 3.0/3.5 is not necessary for your code to run) or later (and can run under CLR 4). This is not recommended for any new projects and is no longer being actively extended (having said that, it does share a core with Sp.Agent and may hence benefit from ongoing bugfixes and performance improvement work)

Sp.Agent: This requires .NET 4.0 raw (i.e. not 4.5 etc.). This is being actively developed and has many new features (e.g.  NuGet support, cleaner APIs, ILMerging support etc.)

The key thing to take from the above is that we have clearly defined minimum platform requirements we take very seriously and hence what you're seeing is definitely not the intention.

 

We internally test with a mix of 4, 4.5, 4.5.1 and other installations and use a mix of VS versions including VS2013 and have not detected any issues of the nature you describe in the course of our testing (or as a reported issue from other customers).

So certainly we wouldn't expect the problems you describe under normal circumstances - i.e., protecting under VS2013 on a Win7/8 or Server 2008+ box with .NET 3.5 installed should Just Work.

Unfortunately, in the absence of an exception or further details, I'm reduced to guessing as to the likely nature and/or cause of your issue and ways in which to narrow down the problem...

-Windows 8 or Server 2012 and later OSes often won't have .NET 3.5 (or 4.0 raw) OOTB which can cause issues. 

-You mention your assembly depending on CLR4. I'll assume 4.0 but you should double check this.

-The protection process, like the compilation process within VS is dependent on the correct .NET Reference Assemblies being present.

-We recommend updating to latest version of the runtimes (you should of course take a backup of the old runtimes and SDK before you do)

-as you appear to already have a .NET 4.0 requirement, we recommend using the Sp.Agent runtime unless you have a good reason not to

I hope the above helps you to narrow the issue. If you need us to assist with reproing, the following inputs would be helpful:

- runtimes installed on your dev/build machines

- exact target runtime version of your code

- exception stacktrace

We're definitely interested in resolving any issues you can describe in more detail and/or assist in reproing.

Thanks,

--Ruben


User avatar
Member
Member
bsar - 11/18/2013 5:39:43 PM
   
RE:Protected Method fails

Dear Ruben,

This is the input that you asked:   Target system: W7 with CLR versions as reported by CLRVER :v2.0.50727, v4.0.30319 and installed .NET frameworks (As per HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework)
  • v2.0.50727
  • v3.0
  • Version=v4.0
  • Version=v4.0,Profile=Client
Build & Protection Environment:  W8.1 with CLR versions as reported by CLRVER:v2.0.50727, v4.0.30319 and installed .NET frameworks (As per HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework)
  • v2.0.50727
  • v3.0
  • Version=v4.0
  • Version=v4.0,Profile=Client
  • Version=v4.0.1
  • Version=v4.0.1,Profile=Client
  • Version=v4.0.2
  • Version=v4.0.2,Profile=Client
  • Version=v4.0.3
  • Version=v4.0.3,Profile=Client
  • Version=v4.5
  • Version=v4.5.1
The protected assembly targets : <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>   For "Runtime/Agent" field in code protector I tried both Standard and SP.Agent and I get similar exception stack traces. Here is my stack trace for SP.Agent method:
Debug, [msotapp.v3.exe:1340:1,User:bsar] - Creating uncached SLMRuntime Id b8cf7 for Sp.Agent.b8cf7, Version=3.2.1944.79, Culture=neutral, PublicKeyToken=5b7832056d5afd0b Debug, [msotapp.v3.exe:1340:1,User:bsar] - LicenseServices.ctor called. Debug, [msotapp.v3.exe:1340:1,User:bsar] - LicenseServices.ctor called. Debug, [msotapp.v3.exe:1340:1,User:bsar] - LicenseServices.PrepareAssemblyData for assembly Microsoft.Licensing.Permutation_b8cf7_2.0, Version=3.2.1944.79, Culture=neutral, PublicKeyToken=5b7832056d5afd0b License: XXXXXXXXXXXXXXXXXXXXX, Level: Evaluation, State: Valid, Expir. Date: 12/31/9999 11:59:59 PM, In Grace period: False Warning: 0 : Rethrowing without original StackTrace: Sp_Agent_b8cf7_3_2_1944_79FF: Failed to load type 'System.Windows.Input.ICommand, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'; Generic-Context=True ---> System.TypeLoadException: Could not load type 'System.Windows.Input.ICommand' from assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMarkHandle stackMark, Boolean loadTypeFromPartialName, ObjectHandleOnStack type) at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, Boolean loadTypeFromPartialName) at System.Type.GetType(String typeName, Boolean throwOnError) at Sp_Agent_b8cf7_3_2_1944_79If.B(String A_0) at Sp_Agent_b8cf7_3_2_1944_79If.A(Sp_Agent_b8cf7_3_2_1944_79z A_0, IExecutionEngineGenericArguments A_1) at Sp_Agent_b8cf7_3_2_1944_79If.A(IExecutionEngineGenericArguments A_0) --- End of inner exception stack trace --- at Sp_Agent_b8cf7_3_2_1944_79If.A(IExecutionEngineGenericArguments A_0) at Sp_Agent_b8cf7_3_2_1944_79Iw.D(IExecutionEngineGenericArguments A_0) at Sp_Agent_b8cf7_3_2_1944_79Ij.A(IExecutionEngineGenericArguments A_0, Sp_Agent_b8cf7_3_2_1944_79IJ A_1) at Sp_Agent_b8cf7_3_2_1944_79Ij.B(IExecutionEngineGenericArguments A_0, Sp_Agent_b8cf7_3_2_1944_79IJ A_1) at Sp_Agent_b8cf7_3_2_1944_79Ij.A(IExecutionEngineGenericArguments A_0, Sp_Agent_b8cf7_3_2_1944_79A A_1) at Sp_Agent_b8cf7_3_2_1944_79Ij.A(Int32 A_0, IExecutionEngineGenericArguments A_1) at Sp_Agent_b8cf7_3_2_1944_79Ij.E(Int32 A_0, IExecutionEngineGenericArguments A_1) at Sp_Agent_b8cf7_3_2_1944_79tG.A(Sp_Agent_b8cf7_3_2_1944_79Ix A_0, Sp_Agent_b8cf7_3_2_1944_79W A_1, Int32 A_2) at Sp_Agent_b8cf7_3_2_1944_79e.A(Sp_Agent_b8cf7_3_2_1944_79Ix A_0) at Sp_Agent_b8cf7_3_2_1944_79a.E(Sp_Agent_b8cf7_3_2_1944_79Ix A_0) at Sp_Agent_b8cf7_3_2_1944_79tS.A(Sp_Agent_b8cf7_3_2_1944_79Ix A_0, Sp_Agent_b8cf7_3_2_1944_79a A_1) at Sp_Agent_b8cf7_3_2_1944_79tS.A(Sp_Agent_b8cf7_3_2_1944_79Ix A_0) at Sp_Agent_b8cf7_3_2_1944_79tS.A(IExecutionEngineParams A_0, Sp_Agent_b8cf7_3_2_1944_79tB A_1) at Sp_Agent_b8cf7_3_2_1944_79tS.A(Byte[] A_0, IExecutionEngineParams A_1, Sp_Agent_b8cf7_3_2_1944_79tA A_2, Boolean A_3) [Failed to load type 'System.Windows.Input.ICommand, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'; Generic-Context=True]
  The above stack trace/errors actually occur in the "Initialization" function which is protected. (I check inside that function for Licensing using the API). I played around with moving some code in a seperate test method and the exception occurs when the Initialization code tries to acces a property implementing the ICommand interface. The same exception occurs  with both Standard and SP.Agent method: "Failed to load type 'System.Windows.Input.ICommand, System, Version=4.0.0.0 ...."   I hope this helps a bit

 


User avatar
InishTech Dev
InishTech Dev
RBartelink - 11/19/2013 10:21:51 AM
   
RE:Protected Method fails

Hi,

Thanks for those details.

We're trying to repro this side and will be in touch when we do.

Can you confirm the exact target framework of your application please? Also, are you targetting AnyCpu or something else? Can you identify whether it's running under the 64 or 32 bit CLR?

(None of the above are restrictions or should be causing problems but the more specifics we have the more likely we'll be able to repro quickly)

Thanks & regards,

--Ruben


User avatar
Member
Member
bsar - 11/19/2013 11:02:49 AM
   
RE:Protected Method fails

 Hi,

the application is targetting AnyCPU and actually runs as a 64bit process in the CLR. Target Framework in VS2013 is set as ".NET Framework 4" and the csproj states <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>

Let me know if you need further information and if I can help you in reproducing this.

Regards

Vassilis


User avatar
Member
Member
bsar - 11/26/2013 11:59:18 PM
   
RE:Protected Method fails

 Hi,

any news on the topic? I have uploaded my binaries hoping that you can rerproduce the issue.

Regards

Vassilis

 


User avatar
Member
Member
ServiceAdmin - 11/27/2013 9:16:37 AM
   
RE:Protected Method fails

 Hi Vassillis,

We apologise for the delay in responding via this forum.  While we have been attempting to communicate in parallel via email re uploading of assemblies etc we clearly should have separately updated this post with the progress we've made in resolving your issue.

We finally replicated the problem and can confirm that it is related to the protection process on a Win8.1 machine, where Code Protector is not processing reference assemblies correctly.

We are working on a fix for this issue as a priority and hope to release it shortly.

We believe this issue is confined to scenarios where one attempts to protect an assembly targetting 4.0 on a Win8.1 machine using Code Protector v3.2.1944 or later.  It is still possible to protect assemblies on Windows platforms other than Win8.1.

We expect to be able to resolve this issue shortly. While we work on a resolution, if you are under pressue to release are you in position to work around the problem by carrying out the protection on a Windows machine other than Win8.1?

Regards

 


User avatar
Member
Member
bsar - 11/27/2013 9:27:42 AM
   
RE:Protected Method fails

 Hi,

and thank you for the feedback. I have initially noticed the problem under a W7 64bit system, after installation of VS2013 (and of course .NET 4.5.1). I can retry the protection chain on that system, but I think the behaviour is exactly the same. So according to my experience this was introduced along with VS2013 and .NET 4.5.1 on the protection machine (no matter W7 or W8).

Regards

Vassilis

 


User avatar
Member
Member
ServiceAdmin - 11/27/2013 11:58:44 AM
   
RE:Protected Method fails

Hi Vasillis,

Thanks for the clarification re Win7 with VS2013 and .NET 4.5.1 as to date we've been unable to replicate the issue on Win7 machines with VS2013 installed

We have successfully replicated the problem on "out of the box" Win8.1 with .NET 4.5.1 (without VS2013 installed) by 

  • building on a Win 7 machine that has VS2012 and 4.5 installed (but targetting 4.0)
  • running Code Protector manually via the UI on the Win8.1 machine. 

(So we believe the issue is related to .NET 4.5.1 - typically encountered on Win8.1 but can obviously arise in other situations e.g. installation of VS2013 can cause upgrade to 4.5.1. )

We have been unable to replicate the problem on a Win7 machine with only 4.0/4.5 installed.

So we believe that protection should work on a machine that does not have 4.5.1 installed e.g. a Win7 machine without VS2013. So if you are under pressure to make a release and you have such a machine environment you should be able to build and protect your 4.0 assemblies.

In any case we are working urgently on a fix for this matter.

Thanks for your patience.

 


User avatar
Member
Member
bsar - 11/27/2013 12:39:16 PM
   
RE:Protected Method fails

 This makes sense, thank you for the clarification. We will manage with a W7 system without .NET4.5.1 installed. Just let us know when a release fixing this issue is available.

Regards

Vassilis


1 2

There are currently no users on-line.

  • Sticky
  • Locked sticky
  • Hot sticky
  • Hot locked sticky
  • Thread
  • Hot thread
  • Locked thread