Reference .csproj File which references other .csproj


is it possible to reference a .csproj from a solution in VL which also references a second .csproj file from within the solution? As long as I have code im my class which uses classes or methods from the referenced project I get errors in VL:

As soon as I comment out the code which uses the other project, it also works in VL:

The goal here is the following: I am developing a small .net library which I dont only want to use in VL. Thats why I seperated the code in different projects and the “VL Project” should reference the “Core Project”.

I attached the small example project. Maybe there is a simple solution which I was not able to find :) (51.4 KB)



You’re right, project to project reference are not supported. As a workaround you’ll have to reference your internal library as a dll.

Thanks for your reply.
If I reference the .dll in the project VL can load the .csproj properly but it seems it does not know the types:

It does also not work, even if I reference the dll directly in VL:

I actually dont want to reference the dll in VL. Because I would lose the ability of hot reload and have to restart vvvv everytime I rebuild the dll.

I found a way by using the explicit type (with namespace) as parameter in the method:

Any Idea why this makes a diiference?

Does it help if you set EnableDynamicLoading in the VLProject.csproj file? It forces the dotnet build system to copy the dependencies to the output folder.

Sadly it does not help. I also need to reference the library .dll in VL. Otherwise VL does not find the correct types:

But the whole point of referencing the .csproj is to get hot reloading to speed up development of the library. Maybe I need to put everything in one C# project for now and split it up later on when I do not change the library project that often.

Did you mean project to project references are not supported YET? Or is this a bigger problem and not likely to get implemented soon?

Thanks so far!

Can’t really give you an estimate here. It’s definitely not on our current agenda. So maybe like you say, putting everything into one project for now and splitting it later is the best approach.