Dependencies, SxS, Manifest, Portable, Resources

[Elroy]

Ok, for decades, in my primary application, I've stored my dependencies in the main program's resources, and pulled them out when I need them. In that application, they're always in a "Dependencies" sub-folder. Here's a line out of the manifest file:

<file name="Dependencies\mscomctl.ocx">

And that has worked perfectly for decades. (Now, I know some have a problem with me wrapping my dependencies into my resources, but I'd rather not rehash that issue in this thread!)

Here's my issue: I'm developing several small "utility" programs, and I'd like them to be portable, but they do have a dependency to that mscomctl.ocx file. So, I'm going to throw it into the resources of each utility program, and unpack it when I need it.

However, rather than take my "Dependencies" sub-folder approach, I'd rather unpack the dependency file into some common folder.

It's my understanding that the %LocalAppData%, %Temp%, etcetera replacement variables will work in a manifest, but I haven't tested that.

So, with that understanding, where's the best place to "set" this mscomctl.ocx dependency file?

Again, I want to stay portable, but I also may not have administrative rights on whatever computer I'm running on. In fact, I absolutely do not want to assume that I do.

Also, in the manifest, I assume that absolute paths (possibly with those replacement variables) will work, although I've never tested that either.

[baka]

when u check dynamically for "ocx", u get an error if its not registered.
why not just do that? if that person has that .ocx u don't need to put it in that folder.

if we talk "path", Im not sure. Im conflicted.
one part of me, don't like that a program put things in my system/programdata folders.
I like it everything in the folder where the tool is.
when I dont want it anymore, I delete it all. gone. byebye.

but, in the same time, if I need that .ocx a lot. its better its in a folder that can be reached by many.

I don't think u need to worry about the path, just put it somewhere.
in windows 7 we have:

C:\Program Files (x86)\Common Files\
C:\Program Files\Common Files\

could also be a place to put it

like

C:\Program Files\Common Files\vb6OCX\

[Elroy]

when u check dynamically for "ocx", u get an error if its not registered.

Baka, that's not correct. That's the whole idea of the SxS technology that we can use dependencies without them being register.

C:\Program Files (x86)\Common Files\
C:\Program Files\Common Files\
C:\Program Files\Common Files\vb6OCX\

I wasn't sure we had access to writing to those without administrative rights.

if we talk "path", Im not sure. Im conflicted.
one part of me, don't like that a program put things in my system/programdata folders.
I like it everything in the folder where the tool is.
when I dont want it anymore, I delete it all. gone. byebye.

but, in the same time, if I need that .ocx a lot. its better its in a folder that can be reached by many.

Yes precisely. The %ProgramData% path also came to mind for me. That might be the best place for it. Either there, or %Temp% or %LocalAppData%. I just don't really know the tradeoffs of those three. I'm thinking %Temp% is wrong because I've got about a dozen of these little utility programs and I'd like them all to use the same copy of mscomctl.ocx. I'll have them check if it's there, and just use it if it is ... otherwise unpack it.

[baka]

C:\Users\***\AppData\
or
%ProgramData%

and \AppData\Elroy\

u can also have a "readme" or "?" information button in your app that tells this stuff.
that all relevant data will be placed there. so people know where to look if they want to delete it or whatever.

[dilettante]

I've never seen anything suggesting that path macros are expanded in application manifest "name" attributes. But I've never tried it either.

And just remember why UAC protects certain filesystem trees: to resist malware infection of executable code believed to be trustworthy.

[Elroy]

I've never seen anything suggesting that path macros are expanded in application manifest "name" attributes. But I've never tried it either.

And just remember why UAC protects certain filesystem trees: to resist malware infection of executable code believed to be trustworthy.

Here's a ChatGPT reply I got earlier (before I made the OP):

The %apppath% replacement variable is a placeholder used in Side-by-Side (SxS) manifests to represent the path to the directory where the application executable is located. It allows you to dynamically reference files or directories relative to the application's location.

When you include %apppath% in a manifest, the Windows operating system replaces it with the actual path to the application's directory at runtime. This allows your application to reference files or dependencies located in the same directory as the application executable without specifying an absolute path.

Here's an example of how %apppath% can be used in a manifest:

<dependency>
  <dependentAssembly>
    <assemblyIdentity type="win32" name="MyDependency" version="1.0.0.0" />
    <file name="%apppath%\MyDependency.dll" />
  </dependentAssembly>
</dependency>

In the example above, the %apppath% variable is used to specify the path to a dependency DLL named "MyDependency.dll". The Windows operating system replaces %apppath% with the actual path to the application's directory when resolving the dependency.

Using %apppath% provides flexibility and portability to your application, as it allows the application to locate and load files relative to its own location, regardless of where it is installed on the system.

It's important to note that the %apppath% replacement variable is specific to SxS manifests and is not a general-purpose environment variable that can be accessed outside of the manifest context.

But I still haven't tested. I'll test soon though.

[dilettante]

That %apppath% seems excruciatingly pointless. Any relative path is already relative to the application's path.

So bad it seems made up of whole cloth.

So much for ChatGPT being of any use for programming. Just bash your head with a rock for insights.