Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VS2022 extension kestrel web server fails to serve test harness #824

Open
wnayes opened this issue Jun 4, 2023 · 0 comments
Open

VS2022 extension kestrel web server fails to serve test harness #824

wnayes opened this issue Jun 4, 2023 · 0 comments

Comments

@wnayes
Copy link
Contributor

wnayes commented Jun 4, 2023

I was trying to switch to using "Engine": "Chrome" in a setup where I have been using the Chutzpah VS2022 extension successfully prior. Switching to the Chrome engine was not working, and I debugged the issue.

The issue is that non-phantom engines force "server mode" in Chutzpah, and server mode seems to not be working in the VS2022 extension. The localhost Kestrel static file server that gets spun up fails to serve any responses.

I debugged the VS2022 extension to identify the specific issue. The problem is that the Chutzpah extension ships an older version of Microsoft.Extensions.Primitives (2.x), and Visual Studio 2022 itself loads a newer version (7.x) that interacts poorly with the rest of Chutzpah's included ASP.NET Core assemblies. (Found in C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\PublicAssemblies I believe.)

Could not load type 'Microsoft.Extensions.Primitives.InplaceStringBuilder' from assembly 'Microsoft.Extensions.Primitives, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
   at Microsoft.Net.Http.Headers.DateTimeFormatter.ToRfc1123String(DateTimeOffset dateTime, Boolean quoted)
   at Microsoft.AspNetCore.Http.HeaderDictionaryTypeExtensions.SetDate(IHeaderDictionary headers, String name, Nullable`1 value)
   at Microsoft.AspNetCore.Http.Headers.ResponseHeaders.set_LastModified(Nullable`1 value)
   at Microsoft.AspNetCore.StaticFiles.StaticFileContext.ApplyResponseHeaders(Int32 statusCode)
   at Microsoft.AspNetCore.StaticFiles.StaticFileContext.<SendAsync>d__49.MoveNext()
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware.<Invoke>d__7.MoveNext()
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.<ProcessRequests>d__185`1.MoveNext() in Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http\HttpProtocol.cs:line 1135

This sort of assembly conflict issue might be similar to what is discussed in #815. The commenter there notes that it might be possible to exclude certain assemblies from the vsix.

I'd also note that the forced server mode seems unnecessary, at least for the Chrome engine setup I'm testing. I seem to be able to work around the issue by disabling Server mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant