Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

.net core (csproj) global.json 'projects' equivalent

With .net core (project.json) I used to switch between nuget packages and source code by adding the path to source code to the projects field in the global.json. After I did that it would add all the projects that it could find in that path that could replace the nuget packages I referenced.

I used this feature alot because I have my own nuget packages that I use, but I want to test the changes in my other project before I publish. But once I switched to Sdk 1.0.0/VS 2017/csproj .net core that feature seemed to disappear.

The alternative is just manually adding each project, switch the references manually (since they are broken up into project, nuget and sdk references), and then after switch it all back.

Any thoughts or advice would be great.

UPDATE: Sounds like there is no equivalent in csproj (as expected), but there are msbuild workarounds for now (As of the initial VS 2017/.NET Core SDK 1.0.0 release)

like image 841
Gekctek Avatar asked Mar 13 '17 21:03

Gekctek


People also ask

What is global json in .NET Core?

The global. json file allows you to define which . NET SDK version is used when you run . NET CLI commands.

Is global json needed?

NET Core SDK version indicates which versions of the . NET Core CLI tools are used. In general, you want to use the latest version of the tools, so no global. json file is needed.

What is an SDK style project?

NET 5 and later projects are associated with a software development kit (SDK). Each project SDK is a set of MSBuild targets and associated tasks that are responsible for compiling, packing, and publishing code. A project that references a project SDK is sometimes referred to as an SDK-style project.

What is UseAppHost?

UseAppHost. The UseAppHost property controls whether or not a native executable is created for a deployment. A native executable is required for self-contained deployments. In . NET Core 3.0 and later versions, a framework-dependent executable is created by default.


1 Answers

Yes, I too had gotten used to this functionality and built my workflow around it. I am still looking for a solution but I'm currently playing with the idea of using conditional logic in the csproj files. Since it's now msbuild, you can do things like this:

    <Choose>
    <When Condition="Exists('..\..\..\MyProject')">
        <ItemGroup>
            <ProjectReference Include="..\..\..\MyProject\src\MyProject\MyProject.csproj" />
        </ItemGroup>
    </When>
    <Otherwise>
        <ItemGroup>
            <PackageReference Include="MyProject" Version="1.0.0" />
        </ItemGroup>
    </Otherwise>
</Choose>

This replaces the hard reference to a package with a conditional that uses a project reference if it can find the source code (in this case the directory), and a package reference if can't.

So by default you would be referencing the package, but if you want to debug one of your projects, you check it out in the location that the conditional checks, and add the project to your solution.

This way you only need to change your solution file (by adding the project) when you want to include source code, instead of rewiring all your project references.

like image 149
Chris Avatar answered Oct 09 '22 08:10

Chris