Comments
Sort by recent activity
We've got your exception reports, thanks for reporting them. This exception was actually hiding another exception; in your case, an incorrect password when trying to login to the webservice to download new reports. Have you overridden the login password when you set up the custom reporting server? / comments
We've got your exception reports, thanks for reporting them. This exception was actually hiding another exception; in your case, an incorrect password when trying to login to the webservice to down...
Verify that everyone using the custom webservice is configured to use the same license key and SQL Server instance (everyone should be using the same SQL Server, not local .mdb files), and that no one has specified a password override in any SmartAssembly.settings file / comments
Verify that everyone using the custom webservice is configured to use the same license key and SQL Server instance (everyone should be using the same SQL Server, not local .mdb files), and that no ...
Are you running SmartAssembly.exe or SmartAssembly.com? The .exe is the GUI interface, the .com is the command-line interface. / comments
Are you running SmartAssembly.exe or SmartAssembly.com? The .exe is the GUI interface, the .com is the command-line interface.
Which version of SmartAssembly are you using? Method parameters are obfuscated starting in version 6.6.2.
Alternatively, you could turn on pruning, which will prune all the method parameter names it can / comments
Which version of SmartAssembly are you using? Method parameters are obfuscated starting in version 6.6.2.
Alternatively, you could turn on pruning, which will prune all the method parameter names i...
If a method is not obfuscated for whatever reason, then the method parameters are not obfuscated. This is so named parameters, reflection, and the like still work.
Bear in mind that, without pdbs, local variables have no names at all. The name displayed in a decompiler is inferred from the type name and operations that act on that variable. / comments
If a method is not obfuscated for whatever reason, then the method parameters are not obfuscated. This is so named parameters, reflection, and the like still work.
Bear in mind that, without pdbs, ...
We're planning on releasing a new version of SA sometime next week. It's currently undergoing final testing. / comments
We're planning on releasing a new version of SA sometime next week. It's currently undergoing final testing.
I've just checked in a fix. We weren't setting the large address aware flag on the PE header of the assembly, which (for some reason) is required on 64-bit assemblies but not 32-bit or AnyCPU. This'll be in the next release of SA. / comments
I've just checked in a fix. We weren't setting the large address aware flag on the PE header of the assembly, which (for some reason) is required on 64-bit assemblies but not 32-bit or AnyCPU. This...
Thanks for the test case, I've reproduced it on my machine, however only if the application is specifically compiled for 64-bit. AnyCPU works fine, which is probably why we haven't picked this up yet. / comments
Thanks for the test case, I've reproduced it on my machine, however only if the application is specifically compiled for 64-bit. AnyCPU works fine, which is probably why we haven't picked this up yet.
What you're trying to do is produce an API on a dll using several input assemblies. Furthermore, the two dlls are compiled using different languages. As you may imagine, this can lead to some unusual results.
Now, .NET is meant to be language-agnostic, but there's obviously some extra metadata on the F# assembly that's required to consume it properly from F#.
My guess is that the F# compiler can only deal with an assembly written in one language - it either treats a dll as C#/VB, or F#, and it uses the FSharpInterfaceDataVersion assembly-level attribute to distinguish the two. Because you've got types from two different languages in the same assembly, the compiler is getting confused, because it either tries to treat F# types as C#, or C# types as F#, it can't mix it.
This looks like a limitation of the F# compiler. If you want this fixed, you could ask the F# team to specify FSharpInterfaceDataVersion on a per-type basis, rather than per-assembly. / comments
What you're trying to do is produce an API on a dll using several input assemblies. Furthermore, the two dlls are compiled using different languages. As you may imagine, this can lead to some unusu...
Out of interest, is your application 64-bit only (as opposed to AnyCPU or 32-bit only)? / comments
Out of interest, is your application 64-bit only (as opposed to AnyCPU or 32-bit only)?