VMware Horizon Community
Douglas42Adams
Enthusiast
Enthusiast

DOT NET's / VC++ redist - where are you putting them ?

Hi All ,

Right Now - if an app is installing or updating DOT NET - we are stopping the provisioning process and placing it ( DOT NET ) on the Gold Image .

Then creating New install machines w/ the new GI that has the Dot Net.. then redoing the install ..

Just curious what most people are doing ?.

Keeping Everything in the App stack that the App stack needs ?.. including that might be considered OS components ?

i.e. Dot net 3.5 and 4.5 are now part of the OS .

We seem to be getting us in trouble the way we are doing it.. i.e. halting the install and throwing the Dot net on the GI .

We also do that for the C++ redistributables .

Im guessing we are doing it the Wrong way ??

How is everyone else doing it ?

Are you keeping everything in the App Stack 100% ?

thanks !

Reply
0 Kudos
7 Replies
Dempseyy93
Enthusiast
Enthusiast

We package C++ Redist, and .NET components for all relevant apps.

With roughly 120 apps in production, the only issues we typically encounter with this packaging method is with Java and legacy apps that have version dependencies.

Otherwise, greenlight from our end!

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

I think it depends on what you would like to do.

We install all middleware (JRE, .Net, all VCRedists) in our golden image. This way applications that are in appstacks can use these versions and you don;t have any interference between appstacks.

Reply
0 Kudos
Bufordx10
Contributor
Contributor

Hi Dempseyy93, does that mean you package it with the App that requires it or the Gold Image? If it is with the app stacks do they ever interfere with each other if one has say C++ 2015 version 26706 and another has C++ 2015 version 32532?

Reply
0 Kudos
Bufordx10
Contributor
Contributor

@Ray_handels  This is what we were trying to do but we ran into some issues an app may have slipped something by us. Then I think we possibly added that same thing or maybe a different version to the Gold image after thus causing us issues. How do you catch that stuff? I'm guessing looking at the AppStack after creation? So if our AppStack has this would you just move C++ or would you move more? Thank you for your help we really appreciate it.

  • Google Chrome (74.0.3729.157)
  • Dexterity Shared Components 16.0 (64-bit) (16.00.0033.000)
  • Microsoft Application Error Reporting (11.0.6560.0)
  • PDF-XChange PRO (7.0.325.1)
  • Microsoft SQL Server 2012 Native Client (11.1.3000.0)
  • Professional Advantage Enhancements for Dynamics GP 2016 ()
  • Open XML SDK 2.0 for Microsoft Office (2.0.5022)
  • SmartList Builder (0.0.1)
  • AnyView 16.00.120 ()
  • Google Update Helper (1.3.34.7)
  • Microsoft Dynamics GP 2016 (16.00.0627.000)
  • Microsoft Lync 2010 SDK Runtime (4.0.7577.125)
  • Visual Basic for Applications (R) Core - English (6.5.10.32)
  • Altec Application Updater (3.2.392.0)
  • Microsoft Visual C++ 2010 x86 Redistributable - 10.0.40219 (10.0.40219)
  • Visual Basic for Applications (R) Core (6.5.10.32)
Reply
0 Kudos
Dempseyy93
Enthusiast
Enthusiast

On closer inspection, it looks like a mix of both.

We have C++ 2013 and 2017, but nothing .NET, or Java related.

This mightn't be ideal for some, but we've rarely encountered issues (if ever) that've been due to a conflict of dependencies; excluding Java as mentioned earlier.

The only problem I see with throwing everything in the gold image is having to update it more regularly to include new/legacy dependencies to keep up with the introduction of new stacks.

While we have full control of AppVolumes in our environment, unfortunately modifying the Gold image is out of our hands and can often take a while for anything to progress.

This is reason enough for us to tack on dependencies in the stack rather than wholly in the image.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

@Ray_handels  This is what we were trying to do but we ran into some issues an app may have slipped something by us. Then I think we possibly added that same thing or maybe a different version to the Gold image after thus causing us issues. How do you catch that stuff? I'm guessing looking at the AppStack after creation? So if our AppStack has this would you just move C++ or would you move more? Thank you for your help we really appreciate it.

We install all available version of the vcredist within our golden image, this way normally an installation that requires this has it in the golden image (and package machine which is a direct clone of the GI) available.

If we do see that another version is being installed then yes, we do install it in the gold image, not in the Appstack. We had an issue with an application recently because it installed an older vcredist, after that all kinds of quirky things started to happen. Luckily a newer version of the application was available. Thing is that this will always be a thing no matter if you use physical or virtual machines.

Appvolumes is easy learn but hard to master. You really need to think things through before starting to package. It saves quite the hassle afterwards.

While we have full control of AppVolumes in our environment, unfortunately modifying the Gold image is out of our hands and can often take a while for anything to progress.

This is reason enough for us to tack on dependencies in the stack rather than wholly in the image.

Really?? Thinking about this I think it would be close to impossible to manage application or any VDI environment for that matter if you don't have full control over the GI. Because Appvolumes integrates within the OS as it does you really need to have control over both those things.. But just my 2 cents though.

Reply
0 Kudos
Dempseyy93
Enthusiast
Enthusiast

Yeah, don't ask.

We work very closely with the SOE guys to improve our AppVolumes environment, however, it's an imperfect way of managing it which we are slowly trying to consolidate...but bureaucracy is a fickle thing.

Reply
0 Kudos