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

This repo fails to build/load in Visual Studio 2019 #4872

Closed
rainersigwald opened this issue Mar 22, 2019 · 7 comments · Fixed by #5239
Closed

This repo fails to build/load in Visual Studio 2019 #4872

rainersigwald opened this issue Mar 22, 2019 · 7 comments · Fixed by #5239
Assignees
Labels
bug Identifies work items for known bugs critical Marks a bug as a must-fix, showstopper issue development-issue Issues encountered while developing RD, not in RD itself difficulty-02-ducky Resolving these involves the internal API, but with relatively easy problems to solve. has-workaround There is some way of working around this limitation / bug that is confirmed to work technical-debt This makes development harder or is leftover from a PullRequest. Needs to be adressed at some point.

Comments

@rainersigwald
Copy link

I got a report of a failure to build this repo, so I wanted to make y'all aware of the problem.

If you try to load Rubberduck.sln (or any individual project) in Visual Studio 2019 (Preview), it will fail. This is because Sunburst.NET.Sdk.WPF/1.0.47 isn't compatible with 2019. From SunburstApps/MSBuildSdks#1, it sounds like Rubberduck should consider migrating to a different approach.

As mentioned there, one option is to wait for .NET Core 3.0 and its associated SDK, which will support WPF projects. But that's not yet released.

@Vogel612 Vogel612 added bug Identifies work items for known bugs critical Marks a bug as a must-fix, showstopper issue difficulty-02-ducky Resolving these involves the internal API, but with relatively easy problems to solve. development-issue Issues encountered while developing RD, not in RD itself labels Mar 22, 2019
@Vogel612
Copy link
Member

Thanks for reporting this. As it stands, I think waiting for .NET Core 3.0 is the thing we want to do. We spent a lot of time to get the csproj files to the "new csproj" format, removing the Sunburst Sdk would imply at least partially reverting that effort.

Sunburst was initially intended as a crutch until the new csproj format supported WPF and WinForms builds correctly, as such this issue is a useful reminder to pay off that particular technical debt :)

@Vogel612 Vogel612 added the technical-debt This makes development harder or is leftover from a PullRequest. Needs to be adressed at some point. label Mar 22, 2019
@Vogel612 Vogel612 self-assigned this Mar 22, 2019
@Vogel612 Vogel612 added this to TODO in CodeName: Cucumber via automation Apr 3, 2019
@retailcoder retailcoder added the has-workaround There is some way of working around this limitation / bug that is confirmed to work label Apr 26, 2019
@Vogel612 Vogel612 added the hacktoberfest Tags issues for Hacktoberfest 2019 label Sep 20, 2019
@bclothier
Copy link
Contributor

As far as I understand it, we cannot use 2019 unless we change the SDK used. OTOH, once we update the SDK, we cannot use 2017 anymore.

The .NET Core 3 and 2019 are already officially released for some time.

So question now is - do we want to move forward on this and require use of 2019 going forward?

@zspitz
Copy link

zspitz commented Oct 22, 2019

@bclothier

once we update the SDK, we cannot use 2017 anymore.

Can you clarify? It's possible to create .NET Framework projects that use the new SDK-style format.

@bclothier
Copy link
Contributor

We already are using the SDK style. The limiting factor is the ability to use WPF & WinForms, which .NET Core enabled support for in version 3 and is not backported to Visual Studio 2017. We were able to transition to SDK format earlier because we used Sunburst SDK which had support (sort of) for WPF & WinForms without requiring us to go to 2019. To use .NET Core 3 and thus get support for WPF/WinForms, it must be on Visual Studio 2019.

@retailcoder
Copy link
Member

Has it been confirmed that VS2019 can actually build Rubberduck? If so, then all we need is a pull request to make it happen.

@bclothier
Copy link
Contributor

I already have a branch that i have not yet pushed building using the extra SDK and it can build 2019 just fine. I need to test it on 2017, however and handle some other mysterious warnings ref.

Using extra SDK might be sufficient to allow us to support both 2017 and 2019, but that needs to be tested.

@mansellan
Copy link
Member

FWIW, I don't see the need to support 2017 any more, 2019 seems plenty stable.

@bclothier bclothier removed the hacktoberfest Tags issues for Hacktoberfest 2019 label Nov 5, 2019
retailcoder added a commit that referenced this issue Jan 8, 2020
Updated Sdk for VS 2019 compatibility. Fixes #4872
CodeName: Cucumber automation moved this from TODO to Done Jan 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Identifies work items for known bugs critical Marks a bug as a must-fix, showstopper issue development-issue Issues encountered while developing RD, not in RD itself difficulty-02-ducky Resolving these involves the internal API, but with relatively easy problems to solve. has-workaround There is some way of working around this limitation / bug that is confirmed to work technical-debt This makes development harder or is leftover from a PullRequest. Needs to be adressed at some point.
Projects
Development

Successfully merging a pull request may close this issue.

6 participants