Rhino versions need different App User Model Ids

Rhino Rhino for Windows
,
1

So I filed a bug internally that when I have Rhino 7 and Rhino 8 running at the same time, they incorrectly combine under the Rhino 7 icon on the taskbar. I thought it was a taskbar bug, because this is the first time I’ve ever seen this happen with an app. It was closed because the team said that both versions of Rhino use the same app id, so there’s nothing the shell/taskbar can do.

I know this is a rare circumstance, but it highlighted the fact that the different Rhino versions are using the same App Ids (explicit or auto-generated by Windows. I assume auto-generated because there are no associated Rhino tasks in the jump list). Ideally, each version of Rhino would have a new app id.

You can read more about these, and why you want to create explicit ones, here.

With just Rhino 8 open

image

With both Rhino 7 and Rhino 8 open

image

Pete

3 Likes
2

This not such a rare problem at all, but a long known issue and there are multiple threads about it going back several years.

1 Like
3

But possibly the first post that holds the solution. What do you think @brian?

2 Likes
4

I allways was under the impression that there is an underlying reason for McNeel not wanting to have distinctive app ids.

5

They’re not doing anything with tasks/jump lists at install time, so I can’t imagine what the reason might be.

The exact response I got from the shell team on this bug was:

The app does not differentiate between the two versions in their app id, so this is not an issue from the taskbar end.

Pete

1 Like
6

I have no clue about programming, I just assumed that they know what they are doing.

1 Like
7

Yeah. It’s not a competence issue at all. Most folks don’t create app ids for apps because it’s completely optional. For the most part, developers only do it when they want more shell / taskbar integration, like creating tasks/jump list items.

Generally not a problem if the apps have different exe names like Rhino7.exe and Rhino8.exe, or if they have internal app ids that are different.

Pete

8

Yeah, I figured that all out about 4 years ago. You can see the comments in RH-60614. Apparently people hated this, too. I’ve not given it serious consideration since then, because I determined that no matter what I do, someone hates it.

Microsoft hates having two apps on the same computer with the same exe name (rhino.exe). But it’s impossible for plugins to load in both versions if we change the name. Thanks dynamic linking!

I’m willing to do this again, and let people hate the way Rhino works with Windows taskbar in a different way. I’m guessing that all y’all reporting this bug are in favor :grin:

9

You can keep same exe names if you register different app Ids. That’s an internal detail and an API call from Rhino, so users shouldn’t be concerned about that at all. See link in my post.

image
image958×556 38.6 KB

From that thread, I’m guessing you only do this for the shortcut, not the API call in the application itself?

Pete

10

Honestly, I don’t remember. I’ll give it another go and see if the shortcuts behave better on Windows 11.

2 Likes
11

I knew there’d be a good reason for deciding against different app names.
Thanks for the info.

12

Not really. That’s why we have APIs to differentiate or associate when you need to.

All three of these are msedge.exe, from different release channels:
image

Plus, every version of Visual Studio for more than a decade has been named devenv.exe. I routinely run both release and preview versions on this PC.

The depends on how you implement your plugin model in your host application. I can see where it might be a problem here, though, and that once set, can’t be changed without breaking that plugin model. This isn’t a good/bad thing, just different applications have plugin models with different needs.

Pete