Splitting a project VB/C#, and References

I've inherited a project written mostly in VB. I'd like to maintain what I have in VB while slowly converting to C# when I can. The only way I've found to do this is to create a separate C# project. However, this causes problems because of dependencies and references. I can'开发者_开发问答t have VBProject reference CSharpProject and vice versa because it creates a circular reference. This is a problem because I need both projects to be able to reference the other. Is there a better way to do this, or am I stuck writing in VB (or completely translating to C#)?

Also, these projects are in the same solution. Shouldn't I be able to import/use them without creating a reference or some other easier way?

There's no getting around having to remove the circular references.

When I've faced a similar situation in the past, converting from language A to language B, I started by refactoring bits of the language A code so that they were independent of the majority of the code base. Then I'd translate those isolated pieces to language B and integrate so that the main program was now depending on the new modules. Eventually, all that was left was the main program.

It took time, but this bottom-up approach was very effective and I ended up with a much more modular program.

Inversion of Control will help you greatly in performing a migration like this. I recently tackled a similar problem when asked to add significant functionality to untested duct-tape VB.Net code. I wanted to extract the existing affected functionality out of VB.Net and put it in a unit tested C# assembly.

In cases where you want to extract a class to a new assembly but would lead to dependencies back in the original assembly you can negate this by defining a contract interface in the new assembly which is implemented by dependencies from the original assembly.

For example, given classes Alpha, Bravo, and Charlie in the VB.Net assembly, where Alpha has a reference to Bravo. You want to extract Bravo, but it has a reference to Charlie. Define an interface called ICharlie in the C# project which contains the members in Charlie that Bravo cares about. In the VB.Net project, modify Charlie : ICharlie. When you construct Bravo, it will accept a dependency of type ICharlie.

The benefit of this approach, even within the same project or set of projects, is testability. Dependencies between classes are well known and can be substituted out with mocks/stubs so that classes like Bravo can be tested without needing to worry about setting it up with a real ICharlie implementation.

You will not be able to do this while the c# project has a dependency on the VB project.

You need to extract classes from the VB.net project into the c# project so that the classes/functions are stand alone and do not depend on the VB project.

This is something I battle against at work every day, and I am slowly moving towards the light (c#)

If you can't extract out specific items into the new C# project to reference, then you'll have to rewrite it all. If it's a web application project or a windows forms project you can't maintain any kind of hybrid in the same project. If you have a website project, you can specify the language for each individual page which would allow you to have a hybrid. This is extremely messy, though, and you will find yourself far better off allocating the time to rewrite it all in C# or adapt to writing in VB.