2

I have a legacy application written in Web Forms and VB .NET. I'm fed up to the back teeth with this combination, so I am trying to write new functionality in Web API controllers instead of ashx handlers. Good for me. I also prefer C# so I am trying to load my controller actions from a C# library instead of writing them in VB .NET.

I have tried to do the following:

  1. Use MapRoute to name an assembly to load from (can't do this, can only see MapHttpRoute, MapRoute is not available. MapHttpRoute has no assembly option)
    1. Write my own assembly resolver to load my other project DLL at runtime. This doesn't work either, VB NET complains about how the code I am using doesn't implement GetAssemblies correctly.

This is the code I am trying to use:

    Public Class CustomAssemblyResolver
    Inherits IAssembliesResolver

    Public Function IAssembliesResolver_GetAssemblies() As ICollection(Of Assembly) Implements IAssembliesResolver.GetAssemblies
        Dim baseAssemblies As List(Of Assembly) = AppDomain.CurrentDomain.GetAssemblies().ToList()
        Dim controllersAssembly = Assembly.LoadFrom("APIControllers.dll")
        baseAssemblies.Add(controllersAssembly)
        Return baseAssemblies
        'Throw New NotImplementedException
    End Function
End Class

The error I get is "Interface IAssembliesResolver is not implemented by this class".

What is the easiest way to load my API controllers from a seperate project? The main project is in VB .NET, the project I am loading is in C#.

EDIT: The issue is complicated by the layout at the moment. For simplicity, oldyuck is the web forms/vb .net thing, and newfast is the new C# project.

oldyuck is the main legacy project. It has a huge monolithic class that does everything. This is instantiated as a huge object that does everything. It's also a Web Forms/VB .NET travesty. newfast is my C# API Controller project. It needs the huge monolithic object from oldyuck to do anything on the database etc.

newfast can depend on oldyuck, and then I can depend on the huge object, and instantiate it etc, but it won't wind up in the /bin/ folder when oldyuck builds.

oldyuck can depend on newfast, and then it will end up in the /bin/ folder. But in this setup, newfast can't depend on the god object from oldyuck, so it can't use any of that code, and there doesn't seem to be a way to pass that object along to it.

I'm stuck. Help :(

Lewis Cianci
  • 926
  • 1
  • 13
  • 38

2 Answers2

1

I'm not sure if I understood it right, but to me it looks just like a reference issue. If that is the kind, it can easily be solved through creating a 3rd project, say GodClassLibrary that contains the God class.

The God class is then removed from Oldyuck, and Oldyuck gets a reference to GodClassLibrary.

And NewFast also gets a reference to GodClassLibrary.

When now compiled, both have their copy of GodClassLibrary in their respective bin folders and can use the legacy code.

Christoph
  • 3,322
  • 2
  • 19
  • 28
0

While it may be possible to use C# Web Api code inside a Web Forms application or vice versa, it is likely to be difficult to maintain or harder to understand for any developers who come after you. I would suggest breaking it down into two separate applications.

When it comes to refactoring a monolith and working with code libraries in multiple frameworks or paradigms there is no one right or wrong answer but I think it is useful to consider if you want to share Code or State.

Sharing code is relatively simple, you should have no issue referencing oldyuck as project dependency of newfast and away you go. Update your build and deploy process to work with 2 applications, and call newfast, perhaps via jQuery direct from the client.

Sharing state can be a lot harder. If your god class maintains a lot of state in ASP.NET Session, then you need to find some way to share it. Take a look at this question for some possible solutions. However it may be simpler to enforce persistence to the database and pass keys around to access the data.

ste-fu
  • 6,879
  • 3
  • 27
  • 46