User profile for Paul.Martin

Yeah that almost certainly will be due to the side-by-side (or not side-by-side) strangeness of Silverlight. With regard to the control flow obfuscation you will probably have to use the "strictly valid" option for Windows Phone Silverlight unless the methods being protected are very small. The standard Microsoft .NET runtimes are fairly relaxed which means that SA can add more protections which are not completely within the spirit of the CLR specification. For non-standard or non-Microsoft runtimes - like Mono and the Windows Mobile version - you generally have to use "strictly valid" otherwise they complain. / comments

Yeah that almost certainly will be due to the side-by-side (or not side-by-side) strangeness of Silverlight. With regard to the control flow obfuscation you will probably have to use the "strictly ...

0 votes

I haven't done any Office interop work, but at a guess something is happening to the Shape struct's data members. Do you define the Shape struct yourself or is it part of the Microsoft.Office.Interop.Visio namespace? What field types are defined in the Shape struct and do any of them have a explicit cast that you have defined? / comments

I haven't done any Office interop work, but at a guess something is happening to the Shape struct's data members. Do you define the Shape struct yourself or is it part of the Microsoft.Office.Inter...

0 votes

With regard to 1) - depending on your coding style pruning is mostly a code optimization process rather than a security process. The main times it will increase security is when you have code with testing hooks, future/obsolete functionality. However it will always improve security of metadata only elements like properties and events (which only exist as metadata and are only there as pointers to the underlying get/set/add/remove methods). Have you excluded the event sink itself from pruning? / comments

With regard to 1) - depending on your coding style pruning is mostly a code optimization process rather than a security process. The main times it will increase security is when you have code with ...

0 votes

I think the problems is that thread you are creating is a foreground thread. There are two types of threads in .NET; background threads will automatically get terminated when an application ends, whereas all foreground threads must exit before the application will exit. Without SA the exception will reach to the JIT debugger which is the only thing that can end all of a processes threads instantly. SA has to add the code to handle the exception otherwise it would fall to the JIT debugger and the user would get two error messages. The most that SA can do is tell the application to exit in every way possible. It could add some really nasty hacky code which went through and terminated all of the threads in the current process, but this wouldn't handle all of the tidying up (e.g. of unmanaged resources) of the other threads. Only thing I can really suggest is to make the thread a background thread (thread.IsBackground = true), as usually you don't need a foreground thread. / comments

I think the problems is that thread you are creating is a foreground thread. There are two types of threads in .NET; background threads will automatically get terminated when an application ends, w...

0 votes

Glad the release version fixed it. Silverlight is rather odd as it doesn't install the runtime libraries side-by-side, unlike the rest of the .NET framework. This means that when you have Silverlight 4 runtimes installed and are trying to build Silverlight 2 and 3 app it has to use the framework libraries from the relevant SDKs. Unfortunately SmartAssembly 4.x didn't handle this stepping back to the SDKs if the Silverlight 4 runtime was installed. / comments

Glad the release version fixed it. Silverlight is rather odd as it doesn't install the runtime libraries side-by-side, unlike the rest of the .NET framework. This means that when you have Silverlig...

0 votes

I think this might be a slightly different problem as cadi is just using CLR2 so shouldn't have multiple different mscorlibs, although the Silverlight framework is slight strange. It is definitely the same cause though as SmartAssembly is having difficulty finding the correct version of the Silverlight framework libraries to use. Can I just confirm a few things (apologies for asking the obvious questions): Your assemblies all target Silverlight 3 and .NET 3.5? The project built fine before you installed the update Did the update install anything else (for instance the Silverlight 4 runtimes as this will cause issues for v4.x)? You might want to try the trial of SmartAssembly 5 (https://www.red-gate.com/dynamic/downloads/downloadform.aspx?download=smartassembly) to see if it fixes the issue. / comments

I think this might be a slightly different problem as cadi is just using CLR2 so shouldn't have multiple different mscorlibs, although the Silverlight framework is slight strange. It is definitely ...

0 votes

There is a different program to run when you want to use the command line version. It is in the same folder as SmartAssembly.exe, but called SmartAssembly.com (or {smartassembly}.com for version 4 and earlier). / comments

There is a different program to run when you want to use the command line version. It is in the same folder as SmartAssembly.exe, but called SmartAssembly.com (or {smartassembly}.com for version 4 ...

0 votes

I think the best answer I can give is ....possibly. It is possible to get SmartAssembly to add error reporting to a DLL, none of which are particularly nice (as described below, it is not sensible for the vast majority of situations, so we discourage it). However, when I tried it for the situation you describe using COM between them it did not work. I'm not sure whether it is something to do with my test programs, or whether there is something on the way COM works for .NET is stopping it. You may get it to work though - I've given the instructions below. / comments

I think the best answer I can give is ....possibly. It is possible to get SmartAssembly to add error reporting to a DLL, none of which are particularly nice (as described below, it is not sensible ...

0 votes

The problem with DLL is that they are intended to be used by an external application. In this schema, throwing exceptions in a must-have. For example, this is the responsibility of the DLL to throw an ArgumentException if a method is not properly called. And the caller (the .EXE) must handle the exception and behave accordingly. So, most of the exceptions must be simply report to the caller. For this very reason, it is not possible to report unhandled exception as a global practice. That's why the option is not available for DLL in {smartassembly}. Anyway, a couple of workaround is available for some kind of DLL (mainly web-services or add-ins) but it requires a few changes in the DLL code (and {smartassembly}'s SDK for the second one): 1) Creating a DLL with an entry point. The trick is to create a Console App EXE instead of a DLL. The only difference between the two is that the Console App has an entry-point. You do nothing in the entry-point (the 'Main' method), but {smartassembly} will add its own code in this method. In the static constructor of your plug-in class, you call the entry-point. class Program { static void Main() { //empty } } class MyPlugin : IPlugin { static MyPlugin() { //ensure that {sa} initialization is executed Program.Main(); } //your code here... } Then, you just have to rename the .EXE into a .DLL, and you have a DLL with an entry-point. 2) Using SmartAssembly.ReportException.dll (Requires the Enterprise edition of {smartassembly}). You need to refer the dependency "C:\Program Files\{smartassembly}\SDK\bin\SmartAssembly.ReportException.dll" (this dependency will be removed when processed by {smartassembly}). Then, for any public method of your DLL that you want to protect, you need to do the following: Of course, you just need to do it for the "entry-points" of your DLL. using SmartAssembly.ReportException; public class MyClass { private void DoSomethingInternal() { //Your code here } public bool DoSomething() { try { DoSomethingInternal(); return true; } catch (Exception exception) { ExceptionReporting.Report(exception); return false; } } } A couple of things to note: - if you use method 1, SmartAssembly has slightly different default obfuscation and pruning settings for applications and libraries (for applications the protection is generally slightly stronger). - if you use method 2, on SmartAssembly 4 you need to manually add option to enable the unhandled exception feature in the project file. If you open the "{sa}proj" file for the library (it is a simple XML file) you need to add the node "<ExceptionReporting ReportExceptions="1" />" under the "Options" section - e.g. <SmartAssemblyProject> <Configuration> ......... <Options> ........... <ExceptionReporting ReportExceptions="1" /> </Options> </Configuration> </SmartAssemblyProject> In SmartAssembly 5 there is an option in the UI to change the setting so you don't have to manually edit the project file. The other method you can use is similar to method 2; however, instead of adding a try/catch to every method, you manually add a handler to the framework's unhandled exception event. The handled exception event varies being different types of applications. For a WPF class library the main one of AppDomain.UnhandledException. So you will want to add something like: Public Sub AppDom_UnhandledExceptions(ByVal sender As Object, ByVal args As UnhandledExceptionEventArgs) Handles _curDomain.UnhandledException SmartAssembly.ReportException.ExceptionReporting.Report(CType(args.ExceptionObject, Exception)) End Sub You will then need to add a static initialiser which links this event handler to the event. / comments

The problem with DLL is that they are intended to be used by an external application. In this schema, throwing exceptions in a must-have. For example, this is the responsibility of the DLL to throw...

0 votes

Ah, I've done a bit of digging and that is a bug. WPF has an extra unhandled exception event in the framework to WinForms. The events common between WPF and WinForms will work on WPF, however, in WPF they are both raised at a point where the application can't continue (it is possible to continue when the extra event in WPF is raised). I've logged a bug in our tracking system (SA-376) for our developers to fix. The only workarounds I can suggest in the meantime is either use the "ReportExceptionAttribute" on every method (which I know would be a real pain), or if you buy the Pro version you just need to add a handler for the missing event: Somewhere near the start of your application add a line: System.Windows.Threading.Dispatcher.CurrentDispatcher.UnhandledException += new System.Windows.Threading.DispatcherUnhandledExceptionEventHandler(App_DispatcherUnhandledException); and then add the method to handle the event void App_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e) { e.Handled = true; SmartAssembly.ReportException.ExceptionReporting.Report(e.Exception); } (note you do need the Pro edition as the SDK, which ReportException.ExceptionReporting is part of, requires the Pro edition or Team package) / comments

Ah, I've done a bit of digging and that is a bug. WPF has an extra unhandled exception event in the framework to WinForms. The events common between WPF and WinForms will work on WPF, however, in W...

0 votes

How can we help you today?

Paul.Martin

Comments