Update projects and build script to .NET SDK 1.0.0-rc3 #360
Conversation
This change adds a couple of environment variables to speed up AppVeyor CI builds: - DOTNET_SKIP_FIRST_TIME_EXPERIENCE=true: Don't download unneeded packages - DOTNET_CLI_TELEMETRY_OPTOUT=true: Don't send telemetry This information was gained from this blog post: http://rehansaeed.com/cross-platform-devops-net-core/
|
Alright, this seems to be working despite the test failures. Those failing tests need to be fixed, they've gone beyond the realm of annoyance. Will work on that tonight. |
| <Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), PowerShellEditorServices.Common.props))\PowerShellEditorServices.Common.props" /> | ||
|
|
||
| <PropertyGroup> | ||
| <AssemblyTitle>PowerShell Editor Services WebSocket Protocol Channel</AssemblyTitle> | ||
| <TargetFrameworks>net451;netstandard1.6</TargetFrameworks> | ||
| <TargetFramework>net451</TargetFramework> |
There was a problem hiding this comment.
So how does this compile for .NET Core now? Via the PackageTargetFallback property below?
There was a problem hiding this comment.
It wasn't even compiling for netstandard1.6 before, I used a condition to take out the list of compiled files for that TargetFramework. That trick didn't seem to work for the new csproj changes so I decided to take the WebSocket projects out of the solution for now. The NuGet dependencies that it uses aren't supported yet on .NET Core unfortunately.
Based on some feedback from some other folks, I think we're going to switch to an HTTP long-polling model instead of WebSockets for a web-based transport.
There was a problem hiding this comment.
Interesting, thanks. BTW what issues did folks have with WebSockets?
There was a problem hiding this comment.
We want to use it in Azure to provide a better PowerShell editing experience, due to the complexity of Azure Resource Manager's architecture, there's no way to maintain a persistent WebSocket connection between a browser and a backend server. Others have been using long-polling for "connected" sessions so I figured it might be better to make that the primary approach.
There was a problem hiding this comment.
One other issue is that AFAIK there is no WebSockets implementation for CoreCLR yet, but maybe that's changing soon.
There was a problem hiding this comment.
Yeah, I thought David Fowler and crew were working on a SignalR implementation for ASP.NET Core due late this year. https://speakerdeck.com/davidfowl/introducing-asp-dot-net-core-sockets
Also this site claims WebSockets is already in CoreFX:
https://apisof.net/catalog/System.Net.WebSockets
No description provided.