build fix for Win11x64 with SDK 22000.0|1 and WDK 22000

geo-y commented 2 years ago

Visual Studio 2019 16.11.11, Windows 11 22000.527, SDK 22000. Building for Win32/x64/ARM64 verified. No new feature added.

Functional test:

USB Camera working.
ADB (< Android 11) device setup working. But ADB debugging can only work with Wifi (adb connect in tcpip way). Direct ADB debugging in usbip connection would cause driver on client crash. It would not bring blue screen but will let your client cannot be rebooted until you poweroff your client pc forcely. This is not bug of this patch.

New vcxproj files:

Common configuration had been extracted into props files.

All the userspace projects had been converted into usb-driver-application which follow the official usb-application template.

To support different targets, properties in visual studio should be edited multiple times. And common settings are hard to synchronized.

"props" files make this easy. (https://docs.microsoft.com/en-us/cpp/build/reference/vcxproj-file-structure?view=msvc-170)

Package project:

Added package project which bring all needed binary files into one folder. Distribution would be very easy.

It is from visual studio driver package template which is common in some driver projects.

(https://github.com/microsoft/Windows-driver-samples/blob/master/audio/simpleaudiosample/Package/package.VcxProj)

<PropertyGroup Label="PropertySheets">
    <PlatformToolset>WindowsKernelModeDriver10.0</PlatformToolset>
    <ConfigurationType>Utility</ConfigurationType>
    <DriverType>Package</DriverType>
    <DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
    <Configuration>Debug</Configuration>
</PropertyGroup>

Build targets:

Appveyor calls the msbuild.rsp which would build x64-release version.

Build different target can do like this:

msbuild usbip_win.sln /property:Configuration=Debug /property:Platform=ARM64 /verbosity:minimal /target:Rebuild

Build offline with test certificate:

and cannot be pushed because appveyor would conflict to it which would cause build freeze. ```xml $(ProjectDir)\..\usbip_test.pfx $(ProjectDir)\..\usbip_test.pfx $(ProjectDir)\..\usbip_test.pfx $(ProjectDir)\..\usbip_test.pfx $(ProjectDir)\..\usbip_test.pfx $(ProjectDir)\..\usbip_test.pfx ``` ### About usbipd-win: usbip-win cannot work with usbipd-win(https://github.com/dorssel/usbipd-win). usbipd-win is using vbox closed source driver which means it is only designed for WSL2. ### Rebuild time consumption: ```txt 1>Time Elapsed 00:00:03.58 2>Time Elapsed 00:00:03.34 4>Time Elapsed 00:00:04.90 7>Time Elapsed 00:00:21.73 6>Time Elapsed 00:00:21.45 3>Time Elapsed 00:00:22.52 8>Time Elapsed 00:00:21.72 5>Time Elapsed 00:00:28.42 9>Time Elapsed 00:00:01.11 ```

cezanne commented 2 years ago

@kody-wen : Thanks for your patch. I agree to get rid of ugly gencat.bat. However, inf2cat of VS requires too much time to be completed and seems to incur unwanted rebuild. Those unpleasant things are gone with Win11 dev? And please check that e7b01fe04b1ea52d4e76db0dda3c4d12386e614e has an error.

geo-y commented 2 years ago

@kody-wen : Thanks for your patch. I agree to get rid of ugly gencat.bat. However, inf2cat of VS requires too much time to be completed and seems to incur unwanted rebuild. Those unpleasant things are gone with Win11 dev? And please check that e7b01fe has an error.

Hi, do you have some logs or screenshots about that error? I would like to help with it.

cezanne commented 2 years ago

@kody-wen:

Hi, do you have some logs or screenshots about that error? I would like to help with it.

My build environment is Win10(1903) SDK&WDK 10.0.18362.0, which is older than yours. You can find build error log in my temporary appveyor build. It is the same with my build log.

cezanne commented 2 years ago

@kody-wen : Thanks for your new work. In my environment, I succeeded to get the package with single warning of package project. But appveyor has raised error and warnings. Please refer to the build log.

By the way, can you answer my old question?

However, inf2cat of VS requires too much time to be completed and seems to incur unwanted rebuild.

If infcat is done by VS, build time takes longer than when used by gencat.bat. Even worse, this delay gets larger when builds are repeated without clean. There's another problem that VS tries to build even though it has been completed to build. This may be build dependency?

cezanne commented 2 years ago

@kody-wen : Please take a look at my old 4c99013a3be15ea5fcb0511aef6929d3dad69c55 for understanding why ugly gencat.bat. is required. Honestly, I had forgot it. 😭

geo-y commented 2 years ago

Time consumption report (Configured VS Build output with Detailed level):

6>    C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Tracker.exe /d "C:\Program Files (x86)\MSBuild\15.0\FileTracker\FileTracker32.dll" /i <Project-Path>\Debug\x64\usbip_vhci_ude\usbip_vhci_ude.tlog /r <PROJECT-PATH>\DEBUG\X64\USBIP_VHCI_UDE\ /b MSBuildConsole_CancelEventb1b5393089284fe8ae09240174251703  /c "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\inf2cat.exe"  /os:10_x64 /USELOCALTIME /driver:<Project-Path>\Debug\x64\usbip_vhci_ude\

4>    C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Tracker.exe /d "C:\Program Files (x86)\MSBuild\15.0\FileTracker\FileTracker32.dll" /i <Project-Path>\Debug\x64\usbip_vhci\usbip_vhci.tlog /r <PROJECT-PATH>\DEBUG\X64\USBIP_VHCI\ /b MSBuildConsole_CancelEvent56612994ab3e4bb192213e6b814d1650  /c "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\inf2cat.exe"  /os:10_x64 /USELOCALTIME /driver:<Project-Path>\Debug\x64\usbip_vhci\

(Long time...)

6>    Signability test complete.

(Long time...)

4>    Signability test complete.

When build Debug mode, each Signability test toke minutes. When build Release mode, it would be very fast to finish the building process. The difference may be related to "Wpp Tracing".

cezanne commented 2 years ago

@kody-wen : Thanks for your great commits. There were a few build errors in my build environment(SDK 18362), which are due to a SDK(18362) bug. Of course, Appveyor build was OK. So, I'm downloading an up-to-date VS and SDK to check your PR. By the way, your commits seem to be better if they are split into smaller ones. For example, removing unnecessary files such as cscope.out would be deserved to be a single commit.

cezanne commented 2 years ago

@kody-wen : From your comment, I realized the exact cause of terrible delay when using VS infcat. VS infcat generates a new tlog file at every build and thus there are plenty of infcat tlogs. So it takes too long for tracker.exe to search build dependecies. Before introducing gencat.bat, I used to clean a project for a workaround. :cry:

Time consumption report (Configured VS Build output with Detailed level):

6>    C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Tracker.exe /d "C:\Program Files (x86)\MSBuild\15.0\FileTracker\FileTracker32.dll" /i <Project-Path>\Debug\x64\usbip_vhci_ude\usbip_vhci_ude.tlog /r <PROJECT-PATH>\DEBUG\X64\USBIP_VHCI_UDE\ /b MSBuildConsole_CancelEventb1b5393089284fe8ae09240174251703  /c "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\inf2cat.exe"  /os:10_x64 /USELOCALTIME /driver:<Project-Path>\Debug\x64\usbip_vhci_ude\

4>    C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Tracker.exe /d "C:\Program Files (x86)\MSBuild\15.0\FileTracker\FileTracker32.dll" /i <Project-Path>\Debug\x64\usbip_vhci\usbip_vhci.tlog /r <PROJECT-PATH>\DEBUG\X64\USBIP_VHCI\ /b MSBuildConsole_CancelEvent56612994ab3e4bb192213e6b814d1650  /c "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\inf2cat.exe"  /os:10_x64 /USELOCALTIME /driver:<Project-Path>\Debug\x64\usbip_vhci\

(Long time...)

6>    Signability test complete.

(Long time...)

4>    Signability test complete.

When build Debug mode, each Signability test toke minutes. When build Release mode, it would be very fast to finish the building process. The difference may be related to "Wpp Tracing".

geo-y commented 2 years ago

@kody-wen : From your comment, I realized the exact cause of terrible delay when using VS infcat. VS infcat generates a new tlog file at every build and thus there are plenty of infcat tlogs. So it takes too long for tracker.exe to search build dependecies. Before introducing gencat.bat, I used to clean a project for a workaround. 😢
Time consumption report (Configured VS Build output with Detailed level):
6>    C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Tracker.exe /d "C:\Program Files (x86)\MSBuild\15.0\FileTracker\FileTracker32.dll" /i <Project-Path>\Debug\x64\usbip_vhci_ude\usbip_vhci_ude.tlog /r <PROJECT-PATH>\DEBUG\X64\USBIP_VHCI_UDE\ /b MSBuildConsole_CancelEventb1b5393089284fe8ae09240174251703  /c "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\inf2cat.exe"  /os:10_x64 /USELOCALTIME /driver:<Project-Path>\Debug\x64\usbip_vhci_ude\

4>    C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Tracker.exe /d "C:\Program Files (x86)\MSBuild\15.0\FileTracker\FileTracker32.dll" /i <Project-Path>\Debug\x64\usbip_vhci\usbip_vhci.tlog /r <PROJECT-PATH>\DEBUG\X64\USBIP_VHCI\ /b MSBuildConsole_CancelEvent56612994ab3e4bb192213e6b814d1650  /c "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\inf2cat.exe"  /os:10_x64 /USELOCALTIME /driver:<Project-Path>\Debug\x64\usbip_vhci\

(Long time...)

6>    Signability test complete.

(Long time...)

4>    Signability test complete.
When build Debug mode, each Signability test toke minutes. When build Release mode, it would be very fast to finish the building process. The difference may be related to "Wpp Tracing".

"Rebuild" is easy for this🤣

cezanne commented 2 years ago

@kody-wen : I have created kody-temp branch which accepted selectively this PR. Those commits on the branch had been cherry-picked into the dev branch. I'm sorry about that all your works can't be merged.

Followings are dropped your works:

VS infcat: due to slow build. SDK 22000 still has the problem.
package project: It seems to be too heavy as a tool for integrating outputs in one place.
.vcxproj & .props: Manual editing project files should be avoided, which are supposed to be modified by VS IDE. And the role of prop file seems to be for unavailable settings via VS IDE.

geo-y commented 2 years ago

No probleam. Should we close this PR now?

cezanne commented 2 years ago

@kody-f : Great thanks..

cezanne / usbip-win