Visual Studio Installer - is it reliable?


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 3 of 3

Thread: Visual Studio Installer - is it reliable?

  1. #1
    Michael Shutt Guest

    Visual Studio Installer - is it reliable?

    I am evaluating the use of Visual Studio Installer and things seems to be
    going fairly well expect for COM registration. The documentation keeps
    reiterating the suggestion to use Windows Installer to do the component
    registration instead of letting the components self-register. I went
    through the pain of adding all of my type library and class info to the
    install project (BTW, how difficult would it be for them to provide and
    import function for this?). The install ran ok and the components were
    apparently registered since the application ran. But I started poking
    around the registry and noticed that the entries are fairly skeletal and
    there appears to be some garbage. For example, under the CLSID entries for
    one of my components, there is an InprocServer32 key with a default value
    pointing to the dll (so far, so good), but then under that key there is a
    value whose name is also InprocServer32 and whose data is just a bunch of
    garbage, i.e.,

    HKEY_CLASSES_ROOT\CLSID\{9EDE23D7-5361-415B-9D28-D7E8DCDC5961}\InprocServer3
    2
    (default): C:\Winnt\System32\MyDll.dll
    InprocServer32: ^&(xg1##$4nsrg

    Also, some of the entries which I consider to be "standard" are missing, for
    example the "TypeLib" entry directly under the {class id} and the
    "ThreadingModel" entry under InprocServer32.

    Has anyone else noticed the same thing using VSI?

    --
    Michael Shutt

    Please respond to newsgroup as I will not return direct emails.




  2. #2
    Michael Culley Guest

    Re: Visual Studio Installer - is it reliable?

    Michael,

    are you saying that the windows installer adds the entries itself, or does
    it just call DllRegisterServer?

    --
    Michael Culley
    www.vbdotcom.com


    "Michael Shutt" <mshutt_nospam@mediaone.net> wrote in message
    news:3c1a6bf0$1@147.208.176.211...
    > I am evaluating the use of Visual Studio Installer and things seems to be
    > going fairly well expect for COM registration. The documentation keeps
    > reiterating the suggestion to use Windows Installer to do the component
    > registration instead of letting the components self-register. I went
    > through the pain of adding all of my type library and class info to the
    > install project (BTW, how difficult would it be for them to provide and
    > import function for this?). The install ran ok and the components were
    > apparently registered since the application ran. But I started poking
    > around the registry and noticed that the entries are fairly skeletal and
    > there appears to be some garbage. For example, under the CLSID entries

    for
    > one of my components, there is an InprocServer32 key with a default value
    > pointing to the dll (so far, so good), but then under that key there is a
    > value whose name is also InprocServer32 and whose data is just a bunch of
    > garbage, i.e.,
    >
    >

    HKEY_CLASSES_ROOT\CLSID\{9EDE23D7-5361-415B-9D28-D7E8DCDC5961}\InprocServer3
    > 2
    > (default): C:\Winnt\System32\MyDll.dll
    > InprocServer32: ^&(xg1##$4nsrg
    >
    > Also, some of the entries which I consider to be "standard" are missing,

    for
    > example the "TypeLib" entry directly under the {class id} and the
    > "ThreadingModel" entry under InprocServer32.
    >
    > Has anyone else noticed the same thing using VSI?
    >
    > --
    > Michael Shutt
    >
    > Please respond to newsgroup as I will not return direct emails.
    >
    >
    >




  3. #3
    Mark Hurd Guest

    Re: Visual Studio Installer - is it reliable?

    Yes, I don't use the VSI yet, but my registry is "full" of these from office
    products and other systems that would have been installed using the installer.

    First time I saw it I thought my registry was corrupt, but that is when I
    noticed it was fairly common, now.

    I noticed it when checking for the current usage of DDEExec registry entries,
    because the Open/command key now has a command value with the same sort of
    gibberish (In a REG_MULTI_SZ). Note that it looks like a tokenised or
    semi-encrypted script:

    10!!!gxsf(Ng]qF`H{LsEXCELFiles>xlT]jI{jf(=1&L[-81-] /e

    However, note the similarity to the default value:

    "E:\Program Files\Microsoft Office\Office\EXCEL.EXE" /e

    and Word's equivalent entries:

    10!!!gxsf(Ng]qF`H{LsWORDFiles>llT]jI{jf(=1&L[-81-] /n
    "E:\Program Files\Microsoft Office\Office\WINWORD.EXE" /n

    A 'random' InprocServer32 entry for MSI Tools mergemod.dll as installed with
    VS.NET Beta2:

    bIWJ--oaLAlW)Q98KJoyVisual_Studio.NET_Professional>Y*yDz+_qF(51*L[5?U{)

    which also looks like a tokenised script...

    [In case of typos: I manually transcribed these registry entries.]

    Anyone read the right manual to know what these things are?

    To see if the missing standard entries are a problem, you could run RegClean
    and see if it adds them in.

    Regards,
    Mark Hurd, B.Sc.(Ma.) (Hons.)

    "Michael Shutt" <mshutt_nospam@mediaone.net> wrote in message
    news:3c1a6bf0$1@147.208.176.211...
    > I am evaluating the use of Visual Studio Installer and things seems to be
    > going fairly well expect for COM registration. The documentation keeps
    > reiterating the suggestion to use Windows Installer to do the component
    > registration instead of letting the components self-register. I went
    > through the pain of adding all of my type library and class info to the
    > install project (BTW, how difficult would it be for them to provide and
    > import function for this?). The install ran ok and the components were
    > apparently registered since the application ran. But I started poking
    > around the registry and noticed that the entries are fairly skeletal and
    > there appears to be some garbage. For example, under the CLSID entries for
    > one of my components, there is an InprocServer32 key with a default value
    > pointing to the dll (so far, so good), but then under that key there is a
    > value whose name is also InprocServer32 and whose data is just a bunch of
    > garbage, i.e.,
    >
    > HKEY_CLASSES_ROOT\CLSID\{9EDE23D7-5361-415B-9D28-D7E8DCDC5961}\InprocServer3
    > 2
    > (default): C:\Winnt\System32\MyDll.dll
    > InprocServer32: ^&(xg1##$4nsrg
    >
    > Also, some of the entries which I consider to be "standard" are missing, for
    > example the "TypeLib" entry directly under the {class id} and the
    > "ThreadingModel" entry under InprocServer32.
    >
    > Has anyone else noticed the same thing using VSI?
    >
    > --
    > Michael Shutt
    >
    > Please respond to newsgroup as I will not return direct emails.
    >
    >
    >




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center