If your property is called MyProperty, you can set it's value with set_MyProperty and you can get it's value with get_MyProperty.ĬLR:: Call /NOUNLOAD SomeAssembly.dll SomeNamespace.SomeClass get_MyProperty 0 pop $0 MessageBox MB_OK $0ĬLR:: Call /NOUNLOAD SomeAssembly.dll SomeNamespace.SomeClass set_MyProperty 1 "Hello Property"
The plug-in is fully functional but still undergoes some development and changes.Ĭurrently you can call properties by using the get_ and set_ notation. NET method that takes no parameters and returns void:ĬLR:: Call /NOUNLOAD SomeAssembly.dll SomeNamespace.SomeClass SomeOtherMethod 0
Omitting the quotes only makes the code slightly easier to read, the result is the same. You do not have to put quotes around the dll filename, namespace, classname and method, but if the dll filename contains spaces, you need the quotes around that. When done with calling CLR::Call, call CLR::Destroy, for instance in. This is nessecary if you need to call CLR::Call more than once, otherwise the installer hangs on the second call. "SomeMethod" 5 "mystring1" "x" 10 15.8 false pop $0 MessageBox MB_OK $0 InitPluginsDir SetOutPath $PLUGINSDIR File "SomeAssembly.dll" CLR:: Call /NOUNLOAD "SomeAssembly.dll" "SomeNamespace.SomeClass" \ NET DLL, which takes five parameters: string, char, int, float and boolean and returns a string: Sample NSIS script calling a method in a. Before calling the plug-in, call SetOutPath and copy the. Return value can be of those types too but are returned as strings to NSIS. Namespace and classname with dot in betweenĪt the moment, the supported parameter types are string, char, int, float and boolean.Place the plugin in the NSIS plugins folder. This Microsoft page describes mult-targeting in excruciating detail.This is a NSIS plug-in, that can call methods in your managed. Unfortunately the current release does not run on VS2010, you can probably compile the source and make it happen, but I haven't tried. Microsoft also provide a Project linker tool that allows for automatic maintenance of projects that have linked files. With help of conditional compilation (a-la good ol' C/C++ days) you can disable stuff that is not supported: public class SerializableExample: IEquatable So now when you compile something that references API missing in Silverlight you get an error: public class SerializableExample: IEquatable, Įrror CS0234: The type or namespace name 'ISerializable' does not exist in the namespace '' (are you missing an assembly reference?) It's a bit of a maintenance nightmare, but at least most errors will be caught at compile time. You can do it manually by adding files as links to the project. NET and Silverlight that share the same source code. The approach recommended by Microsoft is to have separate project for. There are things you can do to make parallel development easier. Considering that potentially some supported system API can use unsupported system API, there is no easy way to work this out ahead of time. NET assembly is that you wouldn't know until runtime which APIs are not supported. Silverlight 3 mscorlib ( rialization namespace): NET 4.0 mscorlib ( rialization namespace): As soon as your assembly tries to hit those API the app goes BOOM!įull. As you can see the two assemblies have some common APIs, but the Silverlight one has a few missing. To demonstrate the difference in APIs, have a look at following screenshots. The silverlight app will compile and run, but as soon as it tries to use a class that is not present in Silverlight, you get a run-time error. Note that you can only add a reference to a compiled assembly and not the project. You can manually edit the silverlight project and add a reference to the normal.
This is not 100% correct as assemblies compiled as Windows libraries will still work under silverlight assuming that they use supported APIs. JaredPar has pointed out the Silverlight CLR is incompatible with normal CLR. A word of warning, my experience on this comes from developing for Windows Phone 7, so this might be subtly different from normal Silverlight 3.