Return to Answer

• Unit testing.

  You can unit test your current project as well. If there is no convenient framework for that, create one.

• Source control.

  Source control deals with text. Your current code is text, therefore you can use source control for it.

  The language, the operating system, the framework or the ecosystem are completely irrelevant. You can (and should) use source control for any code you write: code in Visual Studio, or a piece of code you draft in a few minutes in LINQPad, or PowerShell scripts which automate a task, or database schema, or Excel macros.

• Code documentation - for knowledge transfer to other support persons.

  Agreed.

• Better coding conventions - can use things like ReSharper to enforce better naming and structure.

  Define "better". Are there coding conventions for Excel's macros? If yes, use them: they are not better or worse than any other. If not, create ones and publish them so that other people can use them too. The answers to a question posted in 2010 seem rather disappointing, but there may be new tools available since then.

  Note that the important part of coding conventions is that they should be enforced on commit.

• Better IDE - fewer mistakes due to error highlighting.

  Agreed. The fact that we can't write macros in Visual Studio is very unfortunate.

• More modularity through assemblies - can promote re-use in future tools.

  I'm pretty sure your current product can use some degree of modularity as well.

• Managed deployment - can control who this tool is used by.

  Agreed.

• Unit testing.

  You can unit test your current project as well. If there is no convenient framework for that, create one.

• Source control.

  Source control deals with text. Your current code is text, therefore you can use source control for it.

  The language, the operating system, the framework or the ecosystem are completely irrelevant. You can (and should) use source control for any code you write: code in Visual Studio, or a piece of code you draft in a few minutes in LINQPad, or PowerShell scripts which automate a task, or database schema, or Excel macros.

• Code documentation - for knowledge transfer to other support persons.

  Agreed.

• Better coding conventions - can use things like ReSharper to enforce better naming and structure.

  Define "better". Are there coding conventions for Excel's macros? If yes, use them: they are not better or worse than any other. If not, create ones and publish them so that other people can use them too. The answers to a question posted in 2010 seem rather disappointing, but there may be new tools available since then.

  Note that the important part of coding conventions is that they should be enforced on commit.

• Better IDE - fewer mistakes due to error highlighting.

  Agreed. The fact that we can't write macros in Visual Studio is very unfortunate.

• More modularity through assemblies - can promote re-use in future tools.

  I'm pretty sure your current product can use some degree of modularity as well.

• Managed deployment - can control who this tool is used by.

  Agreed.

• There is no much difference between C# and VB.NET.

• You know VBA better, and this alone is a good reason to use VB.NET instead of C#. If you want to "brush up on your C# skills", do it with your personal projects, not business critical stuff.

• Any rewrite from a language to another leads to potential bugs. You don't need that for this project.

• There is less difference between VBA and VB.NET as there is between VBA and C#.

• You know VBA better, and this alone is a good reason to use VB.NET instead of C#. If you want to "brush up on your C# skills", do it with your personal projects, not business critical stuff.

• Any rewrite from a language to another leads to potential bugs. You don't need that for this project.

Instead of a complete rewrite, you might search for a way to progressively move code from the macro to an ordinary .NET assembly written in VBA. Why in VBA? Three reasons:

• There is no much difference between C# and VBA.

• You know VBA better, and this alone is a good reason to use VBA instead of C#. If you want to "brush up on your C# skills", do it with your personal projects, not business critical stuff.

• Any rewrite from a language to another leads to potential bugs. You don't need that for this project.

Instead of a complete rewrite, you might search for a way to progressively move code from the macro to an ordinary assembly written in VB.NET. Why in VB.NET? Three reasons:

• There is no much difference between C# and VB.NET.

• You know VBA better, and this alone is a good reason to use VB.NET instead of C#. If you want to "brush up on your C# skills", do it with your personal projects, not business critical stuff.

• Any rewrite from a language to another leads to potential bugs. You don't need that for this project.