locked
Is there any sample of assembly type rule instead of script type rule? RRS feed

  • Question

  • Hi there,
    I want to configure a rule programmatically which run a C# compiled assembly instead of probe script. Is there any sample of doing that? thanks!

    --Aaron
    Tell me smth i dont know everyday~~
    Friday, January 29, 2010 3:35 AM

Answers

  • That's pretty much the only way you can run code from an assembly from a script.

    I would warn however, that this will cause an instance of cscript.exe, and a .NET runtime to be instantiated every time the script is run. Performance-wise, you'd be better off using a PowerShell script since the PowerShell module will already have the .NET runtime loaded anyway and will not have to run cscript.exe.
    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    Tuesday, February 9, 2010 10:27 PM

All replies

  • Sorry, so instead of running a .vbs or .ps1 script, you want to run a .NET .exe, for example?
    Friday, January 29, 2010 4:23 PM
  • I found there is a Managed property and a Assembly of ManagementPackModule, i wonder i may set an assembly (dll) to Module and get it run directly. That would be better than command line or script.
    Also, i hope i can use other language than vbs, like python, or c#.


    Tell me smth i dont know everyday~~
    Sunday, January 31, 2010 2:21 AM
  • There are two problems here:

    1) Writing managed module for Operations Manager is pretty complicated task right now
    2) These assemblies should be registred in the GAC. All assemblies which SCOM uses are registred as a part of installation. So, own modules will not work unless they are registered by someone.

    Besides vbscript it is possible to use jscript and powershell. If the problem #2 above is solved somehow then you can write a wrapper in powershell which executes something from your assembly and then returns data to SCOM.
    Thursday, February 4, 2010 4:35 AM
  • If you are using R2, then PowerShell is probably the way to go.

    If you are using SP1, you will end up calling ps.exe every time your workflow runs, which causes the entire PowerShell runtime to be instantiated and then torn down. If you do a lot of processing in your assembly, it won't matter, but if it's quick, the startup overhead of the PowerShell script may be greater than the execution time.

    Another possibility is adding a class to your assembly with the ComVisible attribute set to true and instantiating that from the script like any other COM object. Depending on how much processing, you do in your object, this may be prefereable. Unfortunately, you still have the problem that Zaki mentioned. Your COM object has to be registered on every machine the script will run. (And the script should gracefully deal with a situation where the COM object is missing.)


    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    Friday, February 5, 2010 5:44 PM
  • Thanks the reply of Zaki and Marcin. I have a further question. Supported i use ps. The ps script call an exe (a .Net assembly), how could ps get the 'return value' from exe, lets say return-value is a string or int? Do you have a small piece of sample of it? I am looking for the *best practice* of it. Thanks!


    Tell me smth i dont know everyday~~
    • Edited by Aaron K.B. Huang Saturday, February 6, 2010 12:18 PM added more description
    Saturday, February 6, 2010 12:16 PM
  • Hi Aaron,

    There are two ways:

    1. Do not run .exe (.NET assembly) because it will run it in separate process which will increase overhead. Instead provide dll (still .NET assembly) and use its public objects from ps. Then you might simply execute some method and get a return value as is.
    2. If the only option is to run .exe you will need to analyze its output and parse it. I do not have a sample in ps which does it but I think there should be lots of them in the Internet.

    Between these two options I would go with first (since the second brings overhead as one more process). Also as Marcin said if you develop MP for SCOM 2007 R2 it is highly recommended to use powershell module (instead of running ps from command executer module) since it is much more efficient.

    Thanks,
    Zaki
    Saturday, February 6, 2010 7:34 PM
  • #1 is exactly what i want. Do you have a sample of it? Is it what you said "very complicated task"? BTW, i am using R2.
    Tell me smth i dont know everyday~~
    Sunday, February 7, 2010 2:59 AM
  • The "very complicated task" is creating a managed module type. I wouldn't recommend doing that.

    However, it shouldn't be too difficult to create a PowerShell script and run it using the PowerShell module in R2. The PowerShell script would contain a call inside to load your .NET assembly and do something with the public objects available inside of it.

    Here's a link to an example on how to do that: http://www.leeholmes.com/blog/LoadACustomDLLFromPowerShell.aspx


    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    Monday, February 8, 2010 7:25 PM
  • Marcin,
    Thanks your link. it is very helpful. i also did a small google, and found vbs might be more complicated to do the same task. here is the code i found:
    // bind a variabe to WScript.Shell 
    Set WshShell = CreateObject("WScript.Shell") 
     
    // define the path to the regasm.exe file 
    RegAsmPath = "c:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe" 
     
    // register the dll 
    WshShell.run "cmd /c " & RegAsmPath & " c:\temp\cbsecurity.dll /codebase /nologo /s", 0, True 
     
    // bind a variable to the dll 
    Set cbUtil = CreateObject("CBSecurity.Utilities") 

    Is there any better to load assembly via vbs? I am doing a valuation on both approaches. thanks!

    Tell me smth i dont know everyday~~
    Tuesday, February 9, 2010 9:55 AM
  • That's pretty much the only way you can run code from an assembly from a script.

    I would warn however, that this will cause an instance of cscript.exe, and a .NET runtime to be instantiated every time the script is run. Performance-wise, you'd be better off using a PowerShell script since the PowerShell module will already have the .NET runtime loaded anyway and will not have to run cscript.exe.
    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    Tuesday, February 9, 2010 10:27 PM
  • Got it. I thought i've got everything i need. Thanks! :)
    Tell me smth i dont know everyday~~
    Wednesday, February 10, 2010 2:42 AM