Should we officially retire this tool now that Microsoft have finally delivered their own tool

[mungojam]

See: https://devblogs.microsoft.com/dotnet/introducing-the-net-upgrade-assistant-preview/

It looks like it covers everything and perhaps even takes inspiration from some features like the great walkthrough mode that @andrew-boyarshin implemented. It also tries to remove transitive dependencies which is something we struggled to do.

We could point people towards it in the Readme and in any open issues

@hvanbakel @andrew-boyarshin

[hvanbakel]

I think that's fair. Have you actually tried the tool?

I would want to give it a try first, but official tooling is always better.

On Thu, Mar 4, 2021, 11:57 Mark Adamson [email protected] wrote:

See: https://devblogs.microsoft.com/dotnet/introducing-the-net-upgrade-assistant-preview/

It looks like it covers everything and perhaps even takes inspiration from some features like the great walkthrough mode that @andrew-boyarshin https://github.com/andrew-boyarshin implemented. It also tries to remove transitive dependencies which is something we struggled to do.

We could point people towards it in the Readme and in any open issues

@hvanbakel https://github.com/hvanbakel @andrew-boyarshin https://github.com/andrew-boyarshin

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hvanbakel/CsprojToVs2017/issues/286, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7QKPDWN4DERMDSGLXNOLLTB7Q4FANCNFSM4YT4PBPA .

[maxkatz6]

Does this tool work with old asp.mvc and ef projects?

[mungojam]

I haven't tried it actually and I probably won't get around to with so many things going on at the moment. It would be nice if they recognised projects like yours that have given people a decent option all these years.

It would be cool if anyone watching can give it a go and see how it compares

On Thu, 4 Mar 2021, 21:42 Hans van Bakel, [email protected] wrote:

I think that's fair. Have you actually tried the tool?

I would want to give it a try first, but official tooling is always better.

On Thu, Mar 4, 2021, 11:57 Mark Adamson [email protected] wrote:

See:

https://devblogs.microsoft.com/dotnet/introducing-the-net-upgrade-assistant-preview/

It looks like it covers everything and perhaps even takes inspiration from some features like the great walkthrough mode that @andrew-boyarshin https://github.com/andrew-boyarshin implemented. It also tries to remove transitive dependencies which is something we struggled to do.

We could point people towards it in the Readme and in any open issues

@hvanbakel https://github.com/hvanbakel @andrew-boyarshin https://github.com/andrew-boyarshin

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hvanbakel/CsprojToVs2017/issues/286, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AA7QKPDWN4DERMDSGLXNOLLTB7Q4FANCNFSM4YT4PBPA

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hvanbakel/CsprojToVs2017/issues/286#issuecomment-790965351, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYCFSYSPHJKOERW4RLVNPDTB75CPANCNFSM4YT4PBPA .

[superstrom]

I used try-convert on a couple projects compared to dotnet-migrate-2019, and try-convert does a better job on detecting and adding UseWpf and UseWindowsForms.

I prefer the way that migrate-2019 does the AssemblyInfo transform, as try-convert uses GenerateAssemblyInfo=false. migrate-2019 also removes a couple VS2013-isms like Reference/RequiredTargetFramework and BootstrapperPackage that try-convert keeps.

In my opinion, migrate-2019 still has value, and would hate to see it retired.

[hvanbakel]

I started this literally because I thought it was a problem that Microsoft didn't have a tool for such a repetitive and, in large solutions, time consuming task.

I suggest we just mention the other tool. If you have one project to convert then tooling wasn't that useful anyway. If you have a lot of them then just see which one you prefer.

I'll see if I can put something in the readme this weekend, just mentioning it.

On Fri, Mar 5, 2021, 16:27 superstrom [email protected] wrote:

I used try-convert on a couple projects compared to dotnet-migrate-2019, and try-convert does a better job on detecting and adding UseWpf and UseWindowsForms.

I prefer the way that migrate-2019 does the AssemblyInfo transform, as try-convert uses GenerateAssemblyInfo=false. migrate-2019 also removes a couple VS2013-isms like Reference/RequiredTargetFramework and BootstrapperPackage that try-convert keeps.

In my opinion, migrate-2019 still has value, and would hate to see it retired.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hvanbakel/CsprojToVs2017/issues/286#issuecomment-791810717, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7QKPG7PR7M53YMK3L55ETTCFZH5ANCNFSM4YT4PBPA .

[RichardD2]

The blog post seems to suggest that try-convert will re-target the projects to .NET 5, which is not what I want. At least until there's support for viewing and exporting SSRS reports in .NET 5, I have to stay on .NET 4.8.

I'll be sticking with migrate-2019 for now.