MSH: make-shell error

Discussion in 'Scripting' started by Keith Hill, Dec 15, 2005.

  1. Keith Hill

    Keith Hill Guest

    I tried to make my first custom cmdlet and shell and I get this following
    error. BTW, what was the reasoning again behind having to create a new
    shell for custom commands? Does this mean I might need one shell for Team
    Foundation cmdlets, another shell for Exchange 12 cmdlets, and yet another
    shell for my own custom cmdlets? What if I need to use all three types of
    custom cmdlets in a single shell? This seems a bit too complicated. Why
    can't I just tell MSH where to load my getrandom.dll cmdlet and then party
    on?

    --
    Keith

    PS. The file is in my path

    MSH:91 # which system.management.automation.dll
    C:\Program Files\Microsoft Command Shell\system.management.automation.dll


    Shell NewMsh.exe is created successfully.
    [C:\Bin]
    MSH:89 # C:\Bin\NewMsh.exe

    Unhandled Exception: System.IO.FileNotFoundException: Could not load file or
    ass
    embly 'System.Management.Automation, Version=1.0.60320.0, Culture=neutral,
    Publi
    cKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot
    find t
    he file specified.
    File name: 'System.Management.Automation, Version=1.0.60320.0,
    Culture=neutral,
    PublicKeyToken=31bf3856ad364e35'

    Assembly manager loaded from:
    C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\msc
    orwks.dll
    Running under executable C:\Bin\NewMsh.exe
    --- A detailed error log follows.

    === Pre-bind state information ===
    LOG: User = AGILENT\hillr
    LOG: DisplayName = System.Management.Automation, Version=1.0.60320.0,
    Culture=ne
    utral, PublicKeyToken=31bf3856ad364e35
    (Fully-specified)
    LOG: Appbase = file:///C:/Bin/
    LOG: Initial PrivatePath = NULL
    Calling assembly : NewMsh, Version=0.0.0.0, Culture=neutral,
    PublicKeyToken=null
    ..
    ===
    LOG: This bind starts in default load context.
    LOG: No application configuration file found.
    LOG: Using machine configuration file from
    C:\WINDOWS\Microsoft.NET\Framework\v2
    ..0.50727\config\machine.config.
    LOG: Post-policy reference: System.Management.Automation,
    Version=1.0.60320.0, C
    ulture=neutral, PublicKeyToken=31bf3856ad364e35
    LOG: Attempting download of new URL
    file:///C:/Bin/System.Management.Automation.
    DLL.
    LOG: Attempting download of new URL
    file:///C:/Bin/System.Management.Automation/
    System.Management.Automation.DLL.
    LOG: Attempting download of new URL
    file:///C:/Bin/System.Management.Automation.
    EXE.
    LOG: Attempting download of new URL
    file:///C:/Bin/System.Management.Automation/
    System.Management.Automation.EXE.
     
    Keith Hill, Dec 15, 2005
    #1
    1. Advertisements

  2. I think the current drop does not support a path to the DLL's,
    you can give it with makeshell but not when starting.

    I just make the shell in the MSHhome dir without a path.

    b.t.w. I don't like it either as I have my CMDlets organised somewhere
    elso also.

    gr /\/\o\/\/
     
    /\\/\\o\\/\\/, Dec 15, 2005
    #2
    1. Advertisements

  3. Keith Hill

    lee.holmes Guest

    That is correct. Assembly lookups in .Net to dot follow the same rules that executable lookups do in MSH and cmd.exe. Your support DLL needs to either sit along side the executable that loads it (i.e.: have both in "Microsoft Command Shell" or "C:\Bin,") or exist in the GAC.

    As for your second question, this model isn't something that we would expect many end users to extend their shell with. It solves the need of users that want to create highly controlled shells, and has so far doubled as a method that lets hobbyist users to experiment with Cmdlets and Providers. We have an additional extension mechanism model coming in the next drop that will make the process much less painful for users wanting to experiment with Cmdlets and Providers.

    The design of the upcoming model is very heavily driven by the need to support a strong versioning story. Loading random DLLs from the path opens up lots of opportunity for problems in this area. Not so much for enthusiasts, but potentially more for production environments.

    As always, your constructive feedback (with what works for you, and what does not) will be very valuable to us in helping validate the new model.

    --
    Lee Holmes [MSFT]
    Microsoft Command Shell Development
    Microsoft Corporation
    This posting is provided "AS IS" with no warranties, and confers no rights.

    -----Original Message-----
    From: /\\/\\o\\/\\/
    Posted At: Thursday, December 15, 2005 2:20 AM
    Posted To: microsoft.public.windows.server.scripting
    Conversation: MSH: make-shell error
    Subject: Re: MSH: make-shell error

    I think the current drop does not support a path to the DLL's,
    you can give it with makeshell but not when starting.

    I just make the shell in the MSHhome dir without a path.

    b.t.w. I don't like it either as I have my CMDlets organised somewhere
    elso also.

    gr /\/\o\/\/
     
    lee.holmes, Dec 15, 2005
    #3
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.