VSIX: Allow non-in-place conversion using extension

[zspitz]

Currently, when I choose Convert to VB / Convert to C# on the solution / project context menu, the changes are made in-place to the selected project or solution.

Perhaps the extension should also allow creating the converted solution / project in a different location?

[GrahamTheCoder]

Thanks for getting in touch. With this sort of suggestion I like to understand more about the problem wherever possible before jumping to a solution. Is this a feature you've personally felt a need for, or something you think others might want to do? If you've felt the need for it yourself I'd be interested to know more about your use case and situation.

One example I imagine would be if you want to have old and new solutions open at the same time, and keep tweaking the input then reconverting.

When I designed the current mode of operation I wanted the fewest clicks to let the user immediately see the to what extent the conversion compiled - mainly focusing on their first experience. Obviously someone could just copy paste their solution folder to that place beforehand (or after, and do reset in their VCS), but this could get repetitive. That's a problem I'd be interested to solve.

My worry with the solution of using another location, is the converter has to get involved with copying potentially large amounts of large files (anything in the solution folder) in case they're needed. This could really slow things down, and bring in a whole new category of bugs/errors with hard drive space, and overwriting the destination files etc.

An alternative I wondered about was: At the point the user can currently choose to overwrite files, make the alternative option append a suffix to just the files that would be overwritten. E.g. MySolution.AfterConversion.sln referencing MyProject.AfterConversion.csproj
When they're happy with the conversion they can do a final conversion and select to overwrite. The dialog would need careful wording, but it'd be a reasonably simple solution. Any thoughts?

[zspitz]

I am trying to port an analyzer written in C# for C#, into VB.NET. I wanted to use your conversion tool as a starting point, later modifying the code to use the Roslyn VB.NET nodes instead of the C# nodes. For my use case, I don't need a perfect translation, just something I can scaffold off of.

Obviously someone could just copy paste their solution folder to that place beforehand (or after, and do reset in their VCS), but this could get repetitive.

This is precisely what I did, but I am still left with all the original C# files. This is good for comparisons, but it also means I have to sift through and remove these extra (from the converted project's perspective) files.

(NB: Visual Studio renders hyperlinks in comments as actual clickable hyperlinks. If instead of the original file, there would be a comment like the following:

'converted from file://D:\RoslynClrHeapAllocationAnalyzer2\ClrHeapAllocationsAnalyzer\CallSiteImplicitAllocationAnalyzer.cs

it would be trivial to navigate to the source file. It would be nice to use a relative path, but relative path support apparently isn't built-in to VS.)

make the alternative option append a suffix to just the files that would be overwritten

What bothers me is that the resulting files would still be different than if they had been created originally in the target language.

hard drive space

Would it be enough to perform a disk space check on the existing solution, along with a check for free space on the target location of the conversion. Then, some kind of warning like "The conversion project / solution takes up X on disk. The target location doesn't have that much space."

overwriting the destination files

How complicated would this be?

would really slow things down

Would it be slower than manually copying?

[GrahamTheCoder]

Thanks for the context, very useful to hear what users are actually using it for. That's also just the sort of thing I imagine and hope people use it for 😄

Yep I think it'd be reasonable to put some kind of comment about being converted output at the start of the file. I'd probably make it an option that can be disabled, at least for the tests for example. Feel free to raise an issue / PR for it. I'd be tempted to go for the relative path at the expense of clickability, since I expect people to remove the input files shortly after a successful conversion. Speaking of which, you mentioned sifting, is there a reason you can't just recursively remove *.cs files?

Another thing worthy of an issue/PR would be adding a line to exclude the source languages file extension from the converted project (if they're included by default in new-style <Project Sdk="Microsoft.NET.Sdk"> projects, which I'm guessing is what you're seeing?)

What bothers me is that the resulting files would still be different than if they had been created originally in the target language.

Hmm. I don't quite understand. Doesn't the same thing apply to adding a comment to the top of converted files? What problem does it cause? Incidentally it's not actually the converted files that would get a different name, it's the solution file and the projects that reference the converted projects.

Yes it would be the same speed as doing it manually. But appending suffixes to a few files will be instantaneous. It is perfectly possible to get a good user experience for copying lots of files, but I want to be sure I can see a clear benefit that justifies implementing/maintaining that vs. spending time improving the code conversion itself.

Sorry for asking so many questions, I'm just trying to make the most of the feedback I get