How to build a specific version of oxyplot nuget package locally ?

[xcosmos6]

Hi,
I am having trouble to build a specific version of oxyplot locally so the version number show up correctly for the NUPKG file.
I've cloned the oxyplot repository locally and switched to the release/v2.1.2 branch. However, it does not matter if I build it in visual studio 2019 or 2022, the output NUPKG File always shown as 1.0.0. What am I doing wrong?

Thank you very much!

[VisualMelon]

It's not specified in the project files (it could be; just isn't), so you're not doing anything wrong. Rather, when I publish, I specify the package version on the command line.

dotnet build OxyPlot.CI.sln /p:configuration=Release /p:version=2.1.0

If you want to build in VS, just stuff this into a property group of the csproj

<VersionPrefix>2.1.2</VersionPrefix>

Note also that the version doesn't change anything: if you're building and targeting locally, unless you have your own nuget source it shouldn't matter.

[xcosmos6]

My problem is that I am trying to debug some plot related function in my application and need to step into oxyplot to find out why the null exception throws in oxyplot. Most of the projects in my solution use nuget package 2.1.2, but the one project I am debugging is using a local copy of oxyplot, thus I need to build this local version to 2.1.2 too. Or visual studio barks at me about the different versions of oxyplot I am using.

Thank you very much for the quick response. I will give it a try!

[VisualMelon]

I'd expect the easiest thing to do would be add it as a project reference rather than a nuget package, then it should be fully debuggable without needing to deal with any solution level versioning, but I may be missing some other complexity in your setup.

[xcosmos6]

That's what I did for the project I am debugging where I added oxyplot, oxyplot.wpf and oxyplot.wpf.share as part of my solution, but they build to 1.0.0 instead of 2.1.2, so visual studio was not happy.
So, do you mean if I added them as a project of my solution, the version shouldn't matter? Or, maybe the version should not have shown up at all?
Thanks!

[VisualMelon]

So long as the project referencing the local copy is independent of the others, it should be able to reference any version it likes without a nuget or binary version conflict. What I meant specifically was to add a project reference in the csproj where you need to debug the library, e.g

  <ItemGroup>
    <Reference Include="OxyPlot">
      <HintPath>..\..\oxyplot\Source\OxyPlot\bin\Debug\net6.0\OxyPlot.dll</HintPath>
    </Reference>
  </ItemGroup>

where the path is the path to a locally built copy of OxyPlot. Or

  <ItemGroup>
    <ProjectReference Include="..\..\oxyplot\Source\OxyPlot\OxyPlot.csproj" />
  </ItemGroup>

with the path to the csproj. VS will probably complain about the second one if the project isn't part of the solution, but that's fine: just run dotnet restore for your project and the CLI will pick it up, then it should be debugable from VS. Life will easier if you do add the project to the solution, because it'll let you browse the code for it properly and so place breakpoints more easily.

You do the first of these with the VS UI by doing Open Content Menu for Project in Solution Explorer -> Add Project Reference -> Browser -> (find the .dll). You may need to disable Just My Code so that it lets you step into OxyPlot.

[xcosmos6]

Thank you very much for all the suggestions. The null exception went away after I switch to 2.1.2 from 2.0.0. So I wasn't able to figure out what might have caused it.
Despite the unhappiness of visual studio about the mismatched oxyplot versions, I was able to build and run the project, later, all of a sudden, intellisense stopped complaining too.
Anyway, I was able to finish the work. Thank you very much for maintaining this great project. I will keep using it too.