VS2019 drops .jsproj (UWP JS) support, VS2017 keeps working

[zgramana]

Bug Report

Problem

Cordova Windows projects no longer function in the latest Visual Studio release (2019).

What is expected to happen?

Cordova Windows Visual Studio solutions open, compile, and deploy successfully using the latest Visual Studio release.

What does actually happen?

None of the above.

Information

Command or Code

cordova run windows

Environment, Platform, Device

The official Visual Studio 2019 release drops all support for JavaScript UWP projects. Per it’s release notes:

UWP JavaScript apps are no longer supported in Visual Studio 2019. You cannot create or open JavaScript UWP projects (files with extension jsproj).

As best as I can tell, the only two paths forward for Cordova apps using .NET plugins are 1) Cordova-Electron + Edge.js, or 2) writing a custom UWP host with a full-screen WebView (perhaps using WebView.Interop.

Version information

Checklist

• I searched for existing GitHub issues
• I updated all Cordova tooling to most recent version
• I included all the necessary information above

[janpio]

Ugh, that's a bummer.

Is https://github.com/apache/cordova-electron an appropriate replacement?

[brodycj]

Sure is a shame, I just tweeted this sentiment https://twitter.com/brodybits/status/1115291586223583233

I would consider it a breaking change if Cordova Windows would drop JavaScript or Cordova would drop the existing Windows platform altogether. Basically a big breaking change.

[zgramana]

The key question is what to do about Cordova Windows plug-ins. If you don’t need that, but still want WinJS access to the Universal Runtime API’s, then Microsoft provides tooling. Unfortunately, it also relies on Edge which is now deprecated. However Microsoft is pushing people towards W3C PWA’s, likely paving the way for their eventual replacement for Edge.

To keep Cordova idiomatic on Windows, and allow .NET interop, I would argue option 2 (Full-screen WebView) would be worth pursuing first-if the desire is towards near-term continuity. Option 1 has strong personal appeal to it for me, but it also represents a pretty big re-tool. Option 2 would represent a more incremental change.

That said, it only makes sense if Microsoft will maintain WebView compatibility with its future engine. Really, it’s hard to bet on any future Microsoft roadmap given how unceremoniously it ended wwahost apps and the demise of Edge. Their long-term outlook towards JavaScript in UWP, and hybrid Windows apps at this point seems dim.

[janpio]

For anyone wondering what that looks like in VS19:

Confirmed once again here:

JavaScript Universal Windows Projects are not supported in Visual Studio 2019. To maintain these projects, use Visual Studio 2017.

https://docs.microsoft.com/de-de/visualstudio/porting/port-migrate-and-upgrade-visual-studio-projects?view=vs-2019#project-types (second to last row in the table)

[janpio]

There seems to be a few people that care:
https://developercommunity.visualstudio.com/content/problem/400513/please-dont-remove-javascript-uwp-development-from.html

Some straight answers from MS:

There is no Cordova support in Visual Studio 2019. You will need to stay on Visual Studio 2017 if you require Cordova support in Visual Studio.

https://developercommunity.visualstudio.com/comments/533740/view.html

[janpio]

PWAs might possibly be a viable path forward as well: https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/windows-features This looks pretty much like what UWP JS offered.

[zgramana]

@janpio that’s assuming your project/plugin does not interop with .NET code.

[brodycj]

https://github.com/nodekit-io/nodekit-windows could be a solution to support JavaScript, C#/.NET, and the app store

[janpio]

@zgramana I would have assumed https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/windows-features#call-winrt-apis-from-your-pwa would apply to your own, custom Runtime Components as well. This is not the case?

[zgramana]

@janpio that’s a good question. My research on workarounds focused on finding a solution that will support .NETSTANDARD2.0 libraries, which wwahost.exe does not. I moved on during my research when I saw it mention it uses WWA Host, but it’s possible it’s support for Edge might not be so limited.

I spent a lot of time looking at makeappx.exe-based solutions, so I’ll have to come back to this and take a closer look.

[brodycj]

https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/windows-features#call-winrt-apis-from-your-pwa
[...]

I hope this is still possible on Visual Studio 2019, just raised the following issue: MicrosoftDocs/edge-developer#257

If not, it would be a very unfortunate step backwards (see my comment in MicrosoftDocs/edge-developer#252 (comment)).

I spent a lot of time looking at makeappx.exe-based solutions, so I’ll have to come back to this and take a closer look.

Thanks @zgramana, please keep us posted.

I can think of a couple more alternative workarounds in case we lose support from Visual Studio:

• Support Electron with Windows Store - see https://www.microsoft.com/developerblog/2016/05/08/compiling-electron-apps-for-the-windows-store/
• https://github.com/nodekit-io/nodekit-windows seem to support C#, C++, and JavaScript on Windows

P.S. See also this thread on [email protected]: Native (C#, C++) UI plugins for Cordova Windows?

[zgramana]

@brodybits I should have said that l’ve spent a lot of time exploring Cordova Windows makeappx.exe-based solutions. There’s good stuff on Electron + Windows Store + Background Tasks, and Cordova Windows Store without custom code, but nothing much in Cordova Windows Store with custom code.

I got it working, but it was clunky. I will put it together into a repo to share. Edge.js has some interesting potential, but requires a custom node build, so Electron Windows support needs some tooling updates/enhancements (which perhaps could find a home here).

[janpio]

@janpio that’s a good question. My research on workarounds focused on finding a solution that will support .NETSTANDARD2.0 libraries, which wwahost.exe does not. I moved on during my research when I saw it mention it uses WWA Host, but it’s possible it’s support for Edge might not be so limited.

Current Cordova Windows apps are also run with WWAHost.exe:

if you can include a Runtime Component in those PWA wrapping apps, that might include the same support for native C#/c++ code as Cordova Windows.

Maybe the PWA project even is not that different from a UWP JS .jsproj project?

---

So, who wants to spend some time to investigate this PWA stuff and report back?

(Another relevant discussion: https://developercommunity.visualstudio.com/idea/545987/visual-studio-2019-pwa-guidance.html)

[zgramana]

@janpio indeed, this is how I discovered jsproj was dropped in 2019: I was hoping by installing 2019 I would find wwahost would finally support .NETSTANDARD2.0 libraries.

I’m happy to investigate.

[zgramana]

@janpio I looked into it again today and this approach is not available in 2019. wwahost.exe does not make it beyond 2017, and is tied to jsproj. The makeappx.exe tool uses the Desktop Bridge, so Electron fits nicely since it provides the required executable.

[janpio]

Ok, so many fancy words going around here. Let's see if I got this right:

So "Windows Application Packaging Project", which is described in https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/windows-features#set-up-and-run-your-universal-windows-app, is also a VS17 only thing (and using wwahost.exe in the background)?

makeappx.exe is https://docs.microsoft.com/en-us/windows/uwp/packaging/create-app-package-with-makeappx-tool, correct? Is there any documentation how this could be used to package a web based app / Cordova-www? If not, could you explain it a shortly please?

[brodycj]

The makeappx.exe tool uses the Desktop Bridge, so Electron fits nicely since it provides the required executable.

Makes sense.

So "Windows Application Packaging Project", which is described in https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/windows-features#set-up-and-run-your-universal-windows-app, is also a VS17 only thing (and using wwahost.exe in the background)?

The answer is not clear to me. I tried pushing for clarification in MicrosoftDocs/edge-developer#252 and MicrosoftDocs/edge-developer#257, no official response at this point.

makeappx.exe is https://docs.microsoft.com/en-us/windows/uwp/packaging/create-app-package-with-makeappx-tool, correct?

That is my understanding, but at this point I am too confused to make any definitive statement.

Is there any documentation how this could be used to package a web based app / Cordova-www? If not, could you explain it a shortly please?

I think this should work if the app developer would use the Electron platform (see #327 (comment)). I personally have not worked with the Electron platform and have not tried packaging an electron app for the Windows app store.

I think may be worth investigating how https://github.com/nodekit-io/nodekit-windows is able to package a JavaScript app with C#, as I suggested in #327 (comment). May be more lightweight than using Electron.

[zgramana]

makeappx.exe uses a different toolchain and is based on the Desktop Bridge and is essentially independent of Visual Studio and MSBuild. That means it’s orthogonal to the VS2017/VS2019 .jsproj issue altogether.

Cordova Electron already supports it as a target on Windows. As I noted above, though, it does not provide access to all the capabilities that makeappx.exe provides due to over-abstraction. Some Cordova Windows apps will be unaffected by that.

Many others will find Cordova Electron to be a non-viable alternative. Ironically, the projects most invested in Cordova Windows are the ones most likely to be in this second group.

I have been able to hack around the limits placed on makeappx, but I have not yet been able to work around the limits imposed by makeappx itself. In my opinion, solving both of these two challenges are suitable objectives for this group.

[zgramana]

Combining Cordova Electron with Electron Edge looks promising as a path to a true full replacement.

IIRC, they had some challenges keeping up with the node patching that Edge.js requires, but it feels like a tooling problem that can be solved without too much trouble.

[tjmoore]

I'm a bit confused about PWAs, but it seems the JS code needs to be modified to supply a ServiceWorker object so the browser engine can run it local or offline. I thought though this means you need to publically host the web content to initially fetch it, but possibly you can still locally package the content and serve it from there. https://deletethis.net/dave/2018-05/Win10+PWA+Terminology

That said, this refers to WWAHost, but comments here suggest that has gone away in 2019.

I've got a project that's an LOB local installed JS UWP, which just contains a JS hosted web app. Works great, but no longer supported. It's simply a jsproj and some HTML content and nothing else really. It needs to install and run with no Internet access and without having to host the content on a web server to get it to initially run.

Other thing with this is existing WWA support uses EdgeHTML which is being discontinued in favour of Chromium Edge. Not sure UWP PWA apps support this yet. Noting Chromium Edge as a browser isn't even a UWP app, though I understand there's a WebView2 for Chromium Edge but it's just Win32 C++ at the moment.

[Qws]

This just shows that you shouldn't rely your business on Microsoft... sad to see.

[trajano]

Question about all of this. Considering that it still works in VS2017, there is still some development tooling for the "legacy" code. However, would you still be able to use the code generated from the old tooling?

Google is notorious for actually screwing up more enterprise application deployments because when it deprecates features, it actually breaks backwards compatibility of old applications. Microsoft at least provides workarounds that can co-exist with older executable for the most part (e.g. Internet Explorer still exists and can still run old ActiveX code from older applications).

[janpio]

I don't expect this type of app to ever really stop working, unless Microsoft migrates to 128bit or something in the future. VS2017 also will keep on working for many years, and will probably also get critical updates for quite some time.

It's just unfortunate that this type of app will see future development - because I really liked the concept.

[alexmercerind]

This is not cool. Keep our JavaScript as an option.

[brodycj]

From MicrosoftDocs/edge-developer#252 (comment) it looks to me like someone found a way to develop PWA and UWP apps on VS 2019.

[pjc2007]

Perhaps I am missing something I don't understand here, but could just created a new native UWP application, embed a webview (Webview2), and then host point to local assets that hold all the JS code?

In particular, now with the Webview2 they seem to be talking about/advertising hybrid development.

Also, in my case I now been this chromium based webview, as my application being Ionic/Cordova the latest Ionic has dropped support for the old edge, and hence it's webview. Also other third party components I use are starting to drop old edge as well.

So is if possible to have a new Cordova Windows project/template created, perhaps now in .net 5 Win UI / UWP application, that is supported in VS2019 and beyond, that also contains the new Webview2? Or is there some reason this is just not possible?

[janpio]

If you have a simple application that only runs inside the webview, that could work. Cordova platforms usually also provide access to native features that are not accessible in the webview itself, hence the need to communicate with and execute native code and so on - and that is a lot more complicated to get right.

[pjc2007]

@janpio - yes that is the part I have no idea how it works. Thought there would be some snag :-(

[timbru31]

We are archiving this repository following Apache Cordova's Deprecation Policy. We will not continue to work on this repository. Therefore all issues and pull requests are being closed. Thanks for your contribution.