Comments
Sort by recent activity
You could edit the saproj in a text editor and simply remove the <Assembly> xml element for that assembly, then try and reload the project. / comments
You could edit the saproj in a text editor and simply remove the <Assembly> xml element for that assembly, then try and reload the project.
We've got your error reports.
In your case, the input assembly is invalid. The exception table type for one of the methods in the DeployLX.Licensing.V4 assembly is an invalid value (0x2a). The allowed values according to the CLR spec are 0x1, 0x2, 0x40, or 0x80.
This is probably due to existing obfuscation on that assembly. As a workaround, you could try embedding that assembly instead of merging it, or distribute it separately. / comments
We've got your error reports.
In your case, the input assembly is invalid. The exception table type for one of the methods in the DeployLX.Licensing.V4 assembly is an invalid value (0x2a). The allo...
Sorry you're seeing this problem. We got the exception report you sent in.
This exception is thrown when there is a value in the Constant metadata table of a type we don't expect. From information in your exception report, it looks like it's a constant specified on a parameter of the EnterData.saveSubCategoryData method in the OESReporting assembly. If you have access to the source code of that assembly, could you post (or send us) the definition of that method and information on how you compiled it, or information on where you got the assembly from?
thanks
SimonC / comments
Sorry you're seeing this problem. We got the exception report you sent in.
This exception is thrown when there is a value in the Constant metadata table of a type we don't expect. From information ...
Out of interest, which version of the VB compiler are you using? The compilers in VS 2010 and VS 2008 both produce constants that match up with the CLR specification (the Object type breaks the specification, hence the error message) / comments
Out of interest, which version of the VB compiler are you using? The compilers in VS 2010 and VS 2008 both produce constants that match up with the CLR specification (the Object type breaks the spe...
The attributes dll will be automatically merged into the output assembly for you, so you don't have to redistribute any of the SmartAssembly dlls along with your application.
Alternatively, you can declare your own attributes with the correct name in your source code (for example, DoNotPruneAttribute); when checking attributes, SA only cares about the name of the attribute type, not its namespace or the assembly it comes from. / comments
The attributes dll will be automatically merged into the output assembly for you, so you don't have to redistribute any of the SmartAssembly dlls along with your application.
Alternatively, you can...
The SmartAssembly engine was rewritten in version 6.5. The new engine has completely different performance characteristics to the old one; some customers to see dramatically increased performance, most see little change in performance, and for some the new engine takes longer to process assemblies than the old one.
Which it is depends entirely on the exact makup of the assemblies you're processing and what options you have enabled. Unfortunately, in your case, the new engine takes longer to process your assemblies than the old one. / comments
The SmartAssembly engine was rewritten in version 6.5. The new engine has completely different performance characteristics to the old one; some customers to see dramatically increased performance, ...
Hi ApocDev; I'm currently looking at this issue now.
Just to be clear, you're specifying ExcludePublicMembers on dlls that are being merged in, and you want public members of those merged dlls to still be accessible in the resulting exe? Is this because those members are accessed from other assemblies once they are in the merged exe, or as a shortcut to exclude them from obfuscation?
What was the previous SA version you were using? / comments
Hi ApocDev; I'm currently looking at this issue now.
Just to be clear, you're specifying ExcludePublicMembers on dlls that are being merged in, and you want public members of those merged dlls to s...
It looks like this was a behaviour change introduced in 6.5, with the rearchitecture. ExcludePublicMembers works as documented when specified on the main assembly, but is not properly taken account of when applied to merged assemblies.
This was introduced in 6.5 because we did not take account of SmartAssembly being used to merge assemblies to produce an API on an exe file. Using ExcludePublicMembers on merged assemblies in such a way is somewhat undocumented, which is why we missed it.
We will be fixing this in the next minor release; it is a change that requires some amount of testing to ensure we haven't got any further regressions.
Just to check, have you looked at excluding entire namespaces from obfuscation & pruning in the SmartAssembly UI? That might produce the API you wish without having to use attributes and ExcludePublicMembers. / comments
It looks like this was a behaviour change introduced in 6.5, with the rearchitecture. ExcludePublicMembers works as documented when specified on the main assembly, but is not properly taken account...
Hi smuda, jasonauk.
I've just had a look at this, and 6.6.1.31 has the same behaviour as 6.6.2.35:
- by default, FlagsAttribute is removed from enums by pruning if they aren't publically accessible on a dll. This is because it doesn't affect the operation of the attribute (apart from ToString) and gives information away about how the attribute is meant to be used
- DoNotPruneAttribute specified on a type stops all attributes from being removed from that type, including FlagsAttribute
- Obfuscation does not affect FlagsAttribute
The fix that went into 6.6.1.31 was that SA was removing attributes even when DoNotPrune was specified.
If this is different to what you are experiencing, do let us know. In particular, project settings or exclusions and whether it's a dll or an exe could be affecting the behaviour. If that is the case, please do email support and they'll have a closer look at what's going on.
With regards to the current behaviour, what do you think SA should do? Should it not remove FlagsAttribute at all (and thus leak information about how it is used), should it try and work out when ToString is used on an enum, similar to the heuristics we use to guess when an enum shouldn't be obfuscated, or some other behaviour? / comments
Hi smuda, jasonauk.
I've just had a look at this, and 6.6.1.31 has the same behaviour as 6.6.2.35:
- by default, FlagsAttribute is removed from enums by pruning if they aren't publically accessible...
Unfortunately, this is an artefact of the .NET serialization system. By merging the assemblies defining the serialized classes into another you are changing the assembly identity. To .NET, a serialized instance of [AssemblyA]MyNs.MyType is completely different to [AssemblyB]MyNs.MyType.
In your case, the solution would be to create a SerializationBinder to map between the two assemblies in the merged assembly. / comments
Unfortunately, this is an artefact of the .NET serialization system. By merging the assemblies defining the serialized classes into another you are changing the assembly identity. To .NET, a serial...