locked
Support app as an MMC snap-in? RRS feed

  • Question

  • Hi all,

    I have a Windows Service running which I authored using VB.NET 2010 with SQL Server as back end. The service basically polls folders looking for specific text files. When found it reads the file, extracts the relevant data and imports it into a db table.

    Since the Service is configurable through an initialization file, I am looking into the possibility of building a support app for the application admin so that he (or she) can perform the following activities:

    1. Configure the service (select DB source, folders to poll, trigger times for specific processes, etc.)
    2. Analyze a detailed log text file
    3. Analyze a log kept in the DB
    4. Validate data in the source text files
    5. Monitor process on specific processes

    After doing some research it seems as though these functions might be well suited for an MMC snap-in; however, I am not fully convinced. I have found that the snap-in framework is limited to the functionality that it performs and that snap-ins are targeted more at system administrators and not application admins.

    Also, information on how to build a snap-in is scarce. My original goal was to author it using VB, but so far, all the resources I have found use C# and even those are sketchy.

    What opinions are out there? Is the snap-in the better choice, or could a "normal" Windows forms app be more suited to a non sysadmin?

    Is this the right forum to discuss this? If not, I'll repost on a more relevant location. Thank you for your time and assistance. Saga


    Insanity is the prelude to discovery

    Wednesday, January 16, 2013 10:43 PM

Answers

  • Typically one just uses a Windows Application with an optional ServiceController component if you need to directly interact with the service.  To just change a config file (knowing the user will restart the service to put the changes into effect), a simple Windows Application is all that's needed.

    Typically you fill your MMC with snapins that you use on a regular basis while managing your systems.  Typically a service is configured to do its thing and is rarely adjusted, with the exception of large-scale applications with underlying services (e.g. MS Exchange).  So I would say that it just depends on how much administration you expect your service to require.  I probably wouldn't bother with the MMC snapin unless it was something that would require ongoing administration on a fairly regular basis (again, a good example is MS Exchange).

    That said, this looks like a pretty simple set of instructions for implementing a snap-in:

    http://msdn.microsoft.com/en-us/library/ms692759%28v=vs.85%29.aspx

    Yes, that is C#, however, it is minimal code that pretty much just defines a couple inherited classes with  some attributes.  The VB would be something like:

    Imports Microsoft.ManagementConsole
    Imports System.ComponentModel
    Imports System
    Imports System.Security.Permissions
    
    <Assembly: PermissionSetAttribute(SecurityAction.RequestMinimum, Unrestricted:=True)> 
    Namespace Microsoft.ManagementConsole.Samples
    
        ''' <summary>
        ''' The RunInstaller attribute allows the .Net framework to install the assembly.
        ''' </summary>
        <RunInstaller(True)>
        Public Class InstallUtilSupport
            Inherits SnapInInstaller
        End Class
    
        ''' <summary>
        ''' The main entry point for the creation of the snap-in.
        ''' </summary>
        <SnapInSettings("{CFAA3895-4B02-4431-A168-A6416013C3DD}",
       DisplayName = "- Simple SnapIn Sample",
       Description = "Simple Hello World SnapIn")>
        Public Class SimpleSnapIn
            Inherits SnapIn
            ''' <summary>
            ''' The constructor.
            ''' </summary>
            Public Sub New()
                ' Update tree pane with a node in the tree
                Me.RootNode = New ScopeNode()
                Me.RootNode.DisplayName = "Hello World"
            End Sub
        End Class
    End Namespace
    

    Though I notice that VS2010 doesn't like that PressionSetAttribute delcaration and says that RequestMinimum is obolete then provide a link to more information.  So you'd want to fix that part to apply the attribute value correctly.

    (it looks like this example is more relevant since it uses a Form as the edit control in MMC: http://msdn.microsoft.com/en-us/library/ms692744(v=vs.85).aspx)


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    • Proposed as answer by Paul Ishak Friday, January 18, 2013 12:28 AM
    • Marked as answer by Youen Zen Wednesday, January 23, 2013 6:17 AM
    Wednesday, January 16, 2013 11:16 PM

All replies

  • Typically one just uses a Windows Application with an optional ServiceController component if you need to directly interact with the service.  To just change a config file (knowing the user will restart the service to put the changes into effect), a simple Windows Application is all that's needed.

    Typically you fill your MMC with snapins that you use on a regular basis while managing your systems.  Typically a service is configured to do its thing and is rarely adjusted, with the exception of large-scale applications with underlying services (e.g. MS Exchange).  So I would say that it just depends on how much administration you expect your service to require.  I probably wouldn't bother with the MMC snapin unless it was something that would require ongoing administration on a fairly regular basis (again, a good example is MS Exchange).

    That said, this looks like a pretty simple set of instructions for implementing a snap-in:

    http://msdn.microsoft.com/en-us/library/ms692759%28v=vs.85%29.aspx

    Yes, that is C#, however, it is minimal code that pretty much just defines a couple inherited classes with  some attributes.  The VB would be something like:

    Imports Microsoft.ManagementConsole
    Imports System.ComponentModel
    Imports System
    Imports System.Security.Permissions
    
    <Assembly: PermissionSetAttribute(SecurityAction.RequestMinimum, Unrestricted:=True)> 
    Namespace Microsoft.ManagementConsole.Samples
    
        ''' <summary>
        ''' The RunInstaller attribute allows the .Net framework to install the assembly.
        ''' </summary>
        <RunInstaller(True)>
        Public Class InstallUtilSupport
            Inherits SnapInInstaller
        End Class
    
        ''' <summary>
        ''' The main entry point for the creation of the snap-in.
        ''' </summary>
        <SnapInSettings("{CFAA3895-4B02-4431-A168-A6416013C3DD}",
       DisplayName = "- Simple SnapIn Sample",
       Description = "Simple Hello World SnapIn")>
        Public Class SimpleSnapIn
            Inherits SnapIn
            ''' <summary>
            ''' The constructor.
            ''' </summary>
            Public Sub New()
                ' Update tree pane with a node in the tree
                Me.RootNode = New ScopeNode()
                Me.RootNode.DisplayName = "Hello World"
            End Sub
        End Class
    End Namespace
    

    Though I notice that VS2010 doesn't like that PressionSetAttribute delcaration and says that RequestMinimum is obolete then provide a link to more information.  So you'd want to fix that part to apply the attribute value correctly.

    (it looks like this example is more relevant since it uses a Form as the edit control in MMC: http://msdn.microsoft.com/en-us/library/ms692744(v=vs.85).aspx)


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    • Proposed as answer by Paul Ishak Friday, January 18, 2013 12:28 AM
    • Marked as answer by Youen Zen Wednesday, January 23, 2013 6:17 AM
    Wednesday, January 16, 2013 11:16 PM
  • Reed, thanks for the reply and the sample code.

    "depends on how much administration you expect your service to require"

    I would say it will require minimal configuration/administration. As you mention, the service is configured to do its thing. Adjustments are not often needed and analysis is done only when something odd happens, like the input text file having a date of 01011970 where it is not expected.

    I am tending toward a simple application, but will follow up on your code to have a skeletal snap in working for any future needs. Regards, Saga


    Insanity is the prelude to discovery

    Thursday, January 17, 2013 5:57 PM
  • Hi all,

    I have a Windows Service running which I authored using VB.NET 2010 with SQL Server as back end. The service basically polls folders looking for specific text files. When found it reads the file, extracts the relevant data and imports it into a db table.

    Since the Service is configurable through an initialization file, I am looking into the possibility of building a support app for the application admin so that he (or she) can perform the following activities:

    1. Configure the service (select DB source, folders to poll, trigger times for specific processes, etc.)
    2. Analyze a detailed log text file
    3. Analyze a log kept in the DB
    4. Validate data in the source text files
    5. Monitor process on specific processes

    After doing some research it seems as though these functions might be well suited for an MMC snap-in; however, I am not fully convinced. I have found that the snap-in framework is limited to the functionality that it performs and that snap-ins are targeted more at system administrators and not application admins.

    Also, information on how to build a snap-in is scarce. My original goal was to author it using VB, but so far, all the resources I have found use C# and even those are sketchy.

    What opinions are out there? Is the snap-in the better choice, or could a "normal" Windows forms app be more suited to a non sysadmin?

    Is this the right forum to discuss this? If not, I'll repost on a more relevant location. Thank you for your time and assistance. Saga


    Insanity is the prelude to discovery


    I think it would require administrative privileges if these log files are location under the windows or windows\system32 folders.  Reeds code should help towards the snap-in if you need one (reed I will have to save the code from this thread for my own snap-in).

    Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth. - "Sherlock holmes" "speak softly and carry a big stick" - theodore roosevelt. Fear leads to anger, anger leads to hate, hate leads to suffering - Yoda. Blog - http://www.computerprofessions.co.nr

    Thursday, January 17, 2013 8:14 PM
  • The log text files are under the AppData folder in the Users folder structure, but it's assumed that either the admin has access to the folder or the log files are copied and placed somewhere convenient. Saga

    Insanity is the prelude to discovery

    Thursday, January 17, 2013 11:12 PM