Windowscommunitytoolkit: WebView Build Errors in Microsoft.Toolkit.Win32.UI.Controls

[joncamp]

I'm submitting a...

• Bug report (I searched for similar issues and did not find one)

Current behavior

The following build errors are appearing in Microsoft.Toolkit.Win32. The build errors prevent building of local nuget packages, which makes this a blocking issue for certain scenarios.

1>------ Build started: Project: Microsoft.Toolkit.Win32.UI.Controls, Configuration: Debug Any CPU ------ 1>Interop\WinRT\WebViewControlHost.cs(300,41,300,60): error CS1061: 'WebViewControl' does not contain a definition for 'AddPreLoadedScript' and no accessible extension method 'AddPreLoadedScript' accepting a first argument of type 'WebViewControl' could be found (are you missing a using directive or an assembly reference?) 1>Interop\WinRT\WebViewControlHost.cs(1068,41,1068,49): error CS1061: 'WebViewControl' does not contain a definition for 'GotFocus' and no accessible extension method 'GotFocus' accepting a first argument of type 'WebViewControl' could be found (are you missing a using directive or an assembly reference?) 1>Interop\WinRT\WebViewControlHost.cs(1073,41,1073,50): error CS1061: 'WebViewControl' does not contain a definition for 'LostFocus' and no accessible extension method 'LostFocus' accepting a first argument of type 'WebViewControl' could be found (are you missing a using directive or an assembly reference?) 1>Interop\WinRT\WebViewControlHost.cs(1116,41,1116,49): error CS1061: 'WebViewControl' does not contain a definition for 'GotFocus' and no accessible extension method 'GotFocus' accepting a first argument of type 'WebViewControl' could be found (are you missing a using directive or an assembly reference?) 1>Interop\WinRT\WebViewControlHost.cs(1121,41,1121,50): error CS1061: 'WebViewControl' does not contain a definition for 'LostFocus' and no accessible extension method 'LostFocus' accepting a first argument of type 'WebViewControl' could be found (are you missing a using directive or an assembly reference?) 1>Done building project "Microsoft.Toolkit.Win32.UI.Controls.csproj" -- FAILED. ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Expected behavior

Build completes without issue

Minimal reproduction of the problem with instructions

1) Open Microsoft.Toolkit.Win32\Microsoft.Toolkit.Win32.sln in Visual Studio 2017
2) Build
3) Observe the following build errors.

Environment

``
Nuget Package(s):
N/A
Package Version(s):
N/A

Windows 10 Build Number:

• [ ] Creators Update (15063)
• [ ] Fall Creators Update (16299)
• [X] April 2018 Update (17134)
• [ ] Insider Build (build number: )

App min and target version:

• [ ] Creators Update (15063)
• [ ] Fall Creators Update (16299)
• [X] April 2018 Update (17134)
• [ ] Insider Build (xxxxx)

Device form factor:

• [X] Desktop
• [ ] Mobile
• [ ] Xbox
• [ ] Surface Hub
• [ ] IoT

Visual Studio

• [X] 2017 (version: 15.8.1)
• [ ] 2017 Preview (version: )
  ```

[nmetulev]

The win32 packages requires an insider sdk (17713) to build and it might be causing the issue here.

[rjmurillo]

Yes. Please be sure to run .\build\Install-WindowsSdkISO.ps1 with the latest insiders SDK version as first argument. Right now I think we're on 17733 as of d5fc571f93eee403b8e5a24be4fc5b540a6265e1

[pm64]

On a fresh VM, I installed:

• Windows Insider Preview build 17744 (latest)
• Visual Studio 2017
• SDK Insider Preview build 17754 (latest)

Using Powershell, from the WindowsCommunityToolkit directory, I ran .\build\Install-WindowsSdkISO.ps1 17754, which completed without error.

Following this, when building Microsoft.Toolkit.Win32.UI.Controls, I still receive the error "Warning MSB3245 Could not resolve this reference. Could not locate the assembly 'Windows'. Check to make sure the assembly exists on disk" as originally reported by @joncamp.

Are there additional build requirements I'm failing to recognize?

[azchohfi]

Maybe the Install SDK script is not installing all the required SDKs for the Win32 project. The win32 project does require a different SDK (I think it it 17733). @jwilcox1701 , any insight?

[GraniteStateHacker]

Yes, it's looking for 17733, according to what I'm looking at in the directory.build.props file...

[pm64]

Worked like a charm, thanks gentlemen.

[joncamp]

For those that may continue to run into this periodically - the solution that I have found thus far is to look at the Directory.Build.props and then run the associated sdk installer command.

[rjmurillo]

Opened #2501 to share a script I use to determine which Windows SDKs are referenced and their installation state.