We install CRD into a versioned directory precisely to avoid the "file in use" problem. I don't know if the COM component is also installed to that directory, but if so then it seems like that should be sufficient. I'm not very familiar with that side of things though. Zijie, could you take a look?

The COM component is built inside of the remoting_core.dll (//remoting/host/win/BUILD.gn:remoting_core). So, yes, if we prefer to use different folders for each installation, we need to use different class-id. Otherwise, ::CoCreateInstance (//remoting/host/desktop_session_win.cc) may use a wrong version if the old one has not been completed uninstalled and locks the old dll.

But if we split the COM component out of the remoting_core.dll, what Nico suggested becomes reasonable: if the interface or the implementation are not changed, we do not need to update the class-id. Since the dll uses a totally different memory space, the process won't be impacted even an old COM implementation uses old libraries (e.g. //base).
And it also avoids locking file error, updating the COM component is not necessary each time a new version is pushed.

This approach breaks the automation though: if we need to change the interface or the implementation, we need to manually run the midl.exe and edit related files with its output.

zijhiehe: I can't say if the COM component split is worth it (from the distance it seems like a good change, but this might well be a wrong impression), but having to land rebased expected midl outputs would be working-as-designed in  bug  756607 . The midl.py script prints a "copy" command one can run to do the rebaselining, and given that the .idl files don't change much I figured that might be enough. If you want, I could write a "update-midl-outputs.py" script that fully automates updating baselines (in case this is the only concern about making this change).

No, I do not think splitting COM component out of remoting_core.dll is a simple change. But if we do not do that, I have some concerns about reusing a same class-id for different dll files (old v.s. new). I may have a try if it introduces https://bugs.chromium.org/p/chromium/issues/detail?id=137755 again. I will let you know the result later.
Do you believe this should be safe according to other uses?

P.S. Just a random idea, why cannot we execute mc.exe and midl.exe "remotely" on a Windows machine?

Let me provide some background for the motivation for the cross build project :-) The idea is to offer a simple way for developers on Linux for building chrome/win (and to then run the built tests on swarming). If I can make this easy enough to use, I believe this will be a useful build configuration. Granted, checking in outputs of mc and midl is a bit of a cop out [1], but as mentioned on  issue 756607  we only have 4 directories containing idl files (3 of them containing exactly one .idl file, and one containing 3), and only 3 directories containing mc.exe inputs (1 each), and these files change almost never. So checking in the output allows folks to work on almost everything in the build on linux (changing cc files, adding / removing files, adding resources, etc). So requiring a remote windows machine just for these handful inputs makes things to difficult to use, I believe.

Having said that, we don't necessarily have to do anything for this bug if there's no good way forward. remoting isn't needed to build chrome itself and most of its tests, so if this doesn't work it's not a big problem for the cross build. I figured I'd ask, but if it's a lot of work, we can just do nothing for now.


1: I have a reimplementation of mc.exe that does enough to fulfill all of chrome's current needs, but checking in the outputs seemed still like less work. Eventually I'll polish that mc, but writing a midl.exe seems like more work (not sure how much more).

Got you Nico. I will let you know if this is doable in Chromoting side.

Re the "* Figure out enough of the .tlb format to fill in the clsid dynamically, so that we can copy over checked-in outputs and just copy over the clsid" point:

I think I understand the .tlb format well enough now that that might be a real option (https://chromium-review.googlesource.com/#/c/chromium/src/+/693223)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3a468a2b925df77b0ae25356662bce2a4425d67d

commit 3a468a2b925df77b0ae25356662bce2a4425d67d
Author: Nico Weber <thakis@chromium.org>
Date: Fri Oct 06 22:48:00 2017

midl: Make tlb file work with midl 8.1.620 too, reenable check.

I figured out how .tlb files look, see
https://chromium-review.googlesource.com/c/chromium/src/+/693223
(start around line 255 for an overview).  This is possibly overkill
for just this issue, but it will come in handy for making
remoting's midl step with changing UUID implementable.

Bug:  756607 ,  761839 
Change-Id: I2f2eaaaaa524569f6b014c1793109261e94c79b2
Reviewed-on: https://chromium-review.googlesource.com/705995
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507205}
[modify] https://crrev.com/3a468a2b925df77b0ae25356662bce2a4425d67d/build/toolchain/win/midl.py

Let's do the tlb postprocessing thing.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a5b4ef62b27437f70d8cd7fe600dcd9d558bbd74

commit a5b4ef62b27437f70d8cd7fe600dcd9d558bbd74
Author: Nico Weber <thakis@chromium.org>
Date: Mon Oct 09 17:43:52 2017

remoting: Remove DAEMON_CONTROLLER_CLSID.

It's been unused since https://codereview.chromium.org/884713010/
No intended behavior change.

Bug:  453172 , 761839 
Change-Id: I33daae804cedff550209691ab487cbe789b1efa8
Reviewed-on: https://chromium-review.googlesource.com/706796
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507402}
[modify] https://crrev.com/a5b4ef62b27437f70d8cd7fe600dcd9d558bbd74/remoting/host/installer/win/BUILD.gn
[modify] https://crrev.com/a5b4ef62b27437f70d8cd7fe600dcd9d558bbd74/remoting/host/installer/win/generate_clsids.gni
[modify] https://crrev.com/a5b4ef62b27437f70d8cd7fe600dcd9d558bbd74/remoting/host/installer/win/parameters.json
[modify] https://crrev.com/a5b4ef62b27437f70d8cd7fe600dcd9d558bbd74/remoting/host/win/BUILD.gn
[modify] https://crrev.com/a5b4ef62b27437f70d8cd7fe600dcd9d558bbd74/remoting/host/win/get_clsids.py
[modify] https://crrev.com/a5b4ef62b27437f70d8cd7fe600dcd9d558bbd74/remoting/remoting_options.gni

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fc10d000f13aae3905207b94325a6ffa6b44cfe4

commit fc10d000f13aae3905207b94325a6ffa6b44cfe4
Author: Nico Weber <thakis@chromium.org>
Date: Wed Oct 11 01:54:00 2017

Teach midl.py to replace the main class GUID at file-copy time.

Remoting uses a GUID that changes over time for its main class.
midl.py currently just copies over fixed precomputed outputs.
(midl.exe is Windows-only, and we want to be able to build on non-Win).

To make things work, give midl.py a dynamic_guid arg, that, when set,
makes midl.py replace the GUID in the checked-in output with a dynamic
GUID.

The tricky bit is that the GUID also ends up in the binary .tlb file,
which is an undocumented file format. I figured out most of the file
format in https://chromium-review.googlesource.com/c/chromium/src/+/693223
(see around line 26s for an overview). For a dynamic GUID, two things
need to happen:

1. Find where the GUID of the main clas is in the .tlb file, replace it
2. There's a global hash table of all GUIDs. Recompute this hash table
   after changing one of the GUIDs.

midl.py still compares the output of "copy file with replaced GUID"
with the output of running midl.exe when on Windows, which verifies
that the tlb modification does the same thing that midl.exe does.
(But the diff now needs to compare the post-copy files instead of
the checked-in files.)

TBR=sergeyu

Bug:  761839 
Change-Id: I1fcc3202df3cc4f80a41087668c2c60110fa142c
Reviewed-on: https://chromium-review.googlesource.com/707197
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507860}
[modify] https://crrev.com/fc10d000f13aae3905207b94325a6ffa6b44cfe4/build/toolchain/win/midl.gni
[modify] https://crrev.com/fc10d000f13aae3905207b94325a6ffa6b44cfe4/build/toolchain/win/midl.py
[modify] https://crrev.com/fc10d000f13aae3905207b94325a6ffa6b44cfe4/remoting/host/win/BUILD.gn