For several releases now, the Sentinel LDK Envelope is still not able to reliably detect what Envelope Attributes are being used in a .Net assembly. It seems like the Envelope project files, when combined with use of Envelope Attributes in code, are a "mixed bag" of sticky settings that are carried along from previous .Net assembly evaluations. The only way to get the Envelope to correctly show what is going on with an assembly w/attributes referenced by the Envelope project is to create a NEW Envelope project each time. (i.e. can not rely on Envelope project file, since it brings along old interpretations of the assemblies...?)
To illustrate this: Try to build a Release version of a basic WinForms application using C#. Make use of Envelope attributes in the code to define protection settings. Create an Envelope project and observe that it correctly detects that attributes are used in the code (i.e. list of protection settings becomes "read-only" in the Envelope GUI)
Then, remove all use of Envelope-attributes in the code and rebuild the release. Open the Envelope project again, and refresh the list of protection settings for the assembly. The Envelope program still thinks that there are attributes used in the assembly(!) Why does this happen? Does it not re-scan the .Net assembly when user click the Refresh button? Does it "carry-along" sticky settings from the Envelope project file (i.e. from previous Refreshes)?
Adding to the above issues, an Envelope protected WinForm executable, developed w/C# & Visual Studio still does not run if a Form is set to Localizable and/or if a basic Form Icon is defined via Visual Studio designer. This happens when the "Obfuscate Symbols" settings are set to "Exclude resources". There seems to be issues with how the Envelope protection deals with Designer-generated code?
If the Envelope Refresh feature can't even detect if Envelope Attributes are used in the code, how can we trust that it interpret the actual protection settings defined in the attributes?