Learnings about ClickOnce signing in a DevOps pipeline

I have been struggling with getting the signing of a ClickOnce manifest working for at least a week now. At one point I [asked a question](https://github.com/dotnet/sign/issues/844), but closed it when I figured it out. However, in that post I promised a follow-up, and here it is. I think a number of these things should be documented to help others avoid the hours and hours of turmoil I went through, but if not, perhaps this post will help. 😅

1. By default, "sign" signs pretty much everything in sight. Because out application has a lot of third-party DLLs that we don't want signed, we end up using a file list when signing (i.e. "-fl filelist.txt"). In the filelist.txt file, I explicitly included "myapp.application". However, during the signing process, that file gets temporarily renamed, so it doesn't actually get included. Once I used a wildcard to include files, the "myapp.application" got modified with signature information as it should. I only figured that out by walking through the code in the debugger.
2. This tool does provide for a "publisher name" ("-pn"). However, I ignored that thinking it would come from the project or publishing profile. This ended up costing me many hours because "sign" doesn't use those settings. Instead, "sign" uses the certificate's distinguished name. On the surface, that shouldn't have been a problem, but in reality it turned out to be one. We kept getting failures when our app attempted to install, saying "The specified path, file name, or both are too long." With that failure, no shortcut gets created, no entry is made into the "Add or remove programs" list, and no errors are logged in the event log. That made it nearly impossible to figure out what the problem was. I was fortunate that I was eventually able to get a combination short enough to work (in my case it required a three letter application name), and then I discovered that the shortcut in question was "C:\Users\[User Name]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\[Certificate's distinguished name information]\[Suite name]\[Product name].appref-ms". Well, 1) in Windows 11, the part between "Programs\" and "\[Product name].appref-ms" doesn't show up anywhere, which is why it took me so long to figure this out, and 2) our certificate's distinguished name is quite lengthy. Once I used the "-pn", the problem quickly disappeared, but it took me a long time to get there!

Here are some related issues that might help someone, but they are unrelated to "sign", per se.
- For some reason Microsoft's "VSBuild@1" command, with "/target:publish" and "/p:PublishProfile=", publishes not only the ClickOnce files, but also the results of the build all into the same folder. This is salient because it's one of the things that sent me down the path of using "-fl" and hence the problems I encountered with that.
- Initially, just for clarity, I was adding "/p:PublishDir" to the options of "VSBuild@1". That was causing problems for "sign", but to be honest I didn't really track down why. I just found that "sign" worked if I didn't include that option, and went on my way.

Of course it doesn't help that working on a DevOps build pipeline is a little like driving a rover on Mars: any small change still requires a ten minute turn-around. 🤣

Anyway, at the end of the day (well, week or two), I got it all working, and I appreciate this tool. 😊