I cloned a project, but the new project still groups with the old project on the taskbar

Date:November 10, 2015 / year-entry #235
Tags:other
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20151110-00/?p=91992
Comments:    8
Summary:Alternate title from a non-programmer point of view: When I copy an executable to another name, sometimes it groups separately, and sometimes it groups with the original. A customer had a product, let's call it Contoso Designer. They decided to try an experimental new version of Contoso Designer. So they cloned the Contoso Designer project,...

Alternate title from a non-programmer point of view: When I copy an executable to another name, sometimes it groups separately, and sometimes it groups with the original.

A customer had a product, let's call it Contoso Designer. They decided to try an experimental new version of Contoso Designer. So they cloned the Contoso Designer project, and then started changing the parts of the program that were related to the experiment.

When they did this, they noticed that Contoso Designer Experimental and Contoso Designer both grouped together in the taskbar. This isn't what they wanted, because the original and the experimental versions were not replacements for each other; they are separate programs that merely happen to have started out from the same code base.

So they ran another experiment.

They created a scratch project, put a scratch program in it, compiled it, and ran it. They then copied the scratch.exe file to scratch2.exe and ran that one, and it did not group with scratch.exe in the taskbar. Then they cloned the scratch project, recompiled the scratch program, and ran the clone. All three copies were separate in the taskbar.

So what was haunted about their project that caused the clone to have a secret psychic connection to the original, and group together with it? And more important, how do they get it to stop?

The answer is in the Application User Model ID. As we saw some time ago, the Application User Model ID is how the taskbar identifies applications. If two processes have the same Application User Model ID, then they are treated as the same application, even if the physical executable is different. In other words, the program and its clone were following the instructions in that article and saying, "I want these programs to group together."

Given that nudge, the customer wrote back, "Thanks. Updating the call to Set­Current­Process­Explicit­App­User­Model­ID did the trick."

I hope they remembered to update their Start menu shortcut, too.

Comments (8)
  1. skSdnW says:
    November 10, 2015 at 7:15 am

    One annoying thing about application user model ids is that they are a bit hard to debug. GetCurrentProcessExplicitAppUserModelID only works on explicit ids and only on your own process. GetApplicationUserModelId takes a process handle but does not work on desktop apps for some reason…

  2. Douglas says:
    November 10, 2015 at 9:17 am

    What is the .NET equivalent for Set­Current­Process­Explicit­App­User­Model­ID?

  3. dcon says:
    November 10, 2015 at 9:21 am

    Too bad calling SetCurrentProcessExplicitAppUserModelID on Win10 breaks pinning and jumplists…

  4. cheong00 says:
    November 10, 2015 at 5:18 pm

    We have experience something similar before. There was a VB.NET project that we splited and replaced some of the functions to suit some specialized need. And after inital deployment, users reported that both applications won't run together.

    We have to change the Assembly GUID in the AssemblyInfo.vb to allow both program run at the same time.

  5. Jumplist says:
    November 11, 2015 at 1:12 am

    "I hope they remembered to update their Start menu shortcut, too. "

    Thats a very big issue under win10 – if you don't set the Application User Model ID in the start menu shortcut (or if there is no shortcut) pinning to taskbar will result in a duplicate taskbar icon. What a s*** – why depending such a functionality on a shortcut to the program?

  6. Neil says:
    November 11, 2015 at 2:22 am

    Jumplist: Huh, I did wonder why a program without a shortcut resulted in a duplicate taskbar icon when I tried to pin it under Windows 10. Thanks for confirming it!

  7. DWalker says:
    November 12, 2015 at 10:27 am

    Grouping "related" taskbar items always seemed like a silly thing to do.  My various Windows Explorer windows have nothing to do with each other, so I always set my taskbar to "never group".  I avoid a whole class of questions this way!  

  8. Adam Rosenfield says:
    November 13, 2015 at 10:49 am

    @DWalker: Me too!  If I have 3 separable Explorer folder windows (or browser windows, or documents, etc.), I want to see them all in the taskbar so I can very quickly tell what I have open and what their window titles are at a glance.  I tend to not have a huge overall number of windows open, so two rows of the taskbar is enough to see all of my windows.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index