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 ***@***.***> 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 <#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, ***@***.***> 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 ***@***.***> 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 > <#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 <#286 (comment)>, 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 ***@***.***> 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 <#286 (comment)>, 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.