CODEWITHSUNDEEP
c#asp.net-web-apivisual-studio-code.net-coreprojects-and-solutions
Noldor
Noldor

Reputation: 1182

adding reference .net core web api project on vscode

I'm developing a WebApi project on vscode with .Net Core target framework.. I have this scenario that some part of the code (db interactions and common utils) is going to be part of many other separate projects than this particular WebApi project. So I decided to code it separately in another folder as another project..

Yet I can't figure out how I am going to do this.. Whether as a project reference or an output file as dependency, doesn't matter, I couldn't figure out to use second project in the first one.. I just basically want to build a library compatible with .net core, and use it in many other .net core projects.

I need some guideline and best practice suggestions here.

UPDATE :

I think i've found a way and it seems to be working for now.

1- Adding <ProjectRefence> to FirstProject.csproj file :

<ProjectReference Include="..\SecondProject\SecondProject.csproj"></ProjectReference>

2- Add a project.json file to FirstProject and setting a dependency for SecondProject.

{
    "dependencies": {
        "SecondProject": {
            "target": "project"            
        }
    }
}

3- dotnet restore and build.

4- Restart vscode for proper intellisence.

UPDATE 2020

I was just too new to VS Code environment when I asked this question. I was expecting some IDE features for referencing projects to each other.

Upvotes: 0

Views: 3798

Answers (1)

Ken Mason
Ken Mason

Reputation: 712

Depending on your OS / IDE / version of .Net Core, you may or may not need the CSPROJ update. I think you need them present with .Net Core 2+ / VS17+, and probably some other permutations of tooling.

You may need to expand your dependencies block. I found that based on OS and IDE, sometimes I needed to specifically call out some of the dependencies; they didn't always carry over transitively. For example, I ended up with a block like this when referencing another project, to get things compiling:

"dependencies": { "Microsoft.NETCore.App": { "version": "1.1.0", "type": "platform" }, "NETStandard.Library": "1.6.1", ... "OtherProjectNameHere": { "target": "project" } },

Your specific set of dependencies will vary.

You may also need to make adjustments to the frameworks block in similar spirit.

A more rigorous option you can consider is to put your library / SecondProject into its own repository, and work with it as a NuGet package. If this is a library you're going to use across many projects or many teams, you may benefit from a package reference rather than a project reference. You'd gain:

  • Version numbers for your library, so that you can more easily answer questions like "are my changes to that library included in my build of this app", and all of the peripheral benefits that go with versioning.
  • Separation of concerns, to ensure your library stays general purpose and doesn't end up with hard-coded stuff for the one app.
  • More easily add references (just a version number, like anything else)
  • More easily share the library with other teams. ... and more.

In short, libraries are products, too. You may want to treat it like one, if you're in a company / situation where that makes sense.

Upvotes: 1

Related Questions