NuGet and Package Sources

I'm looking to see if there's a way to swap the source for a NuGet feed based on the selected project configuration (Debug / Release), I have tried various things with nuget.config and nothing seems to work.

For example something like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>		
	<configurations>
        <Debug>
			<packageSources>
                <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
                <add key="SomeRepo" value="C:\LocalRepo"/>
            </packageSources>
		</Debug>
        <Release>
            <packageSources>		
			    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
                <add key="SomeRepo" value="https://live.somerepo/v3/index.json"/>
            </packageSources>
		</Release>
    </configurations>
</configuration>

The reason I'm looking to do this is because when developing locally I have a shared component which kicks out a nuget package to a local folder which is then referenced by this project. On the build server (Azure DevOps) this isn't the case, there is a pipeline / artifacts feed which has a "Release" version of the component I want the project to reference when being built. Hopefully this makes sense, the reason I don't want to reference the release version of the nuget package locally is that I may need to add / change the package and build it locally for speed, instead of having to commit the change, create a pull request, get it reviewed, wait for a build ....

If anyone has any suggestions or is able to help I would really appreciate it.

Thanks in advance

The easiest way to do this is to swap out the entire nuget.config file (or to use a machine-wide config file, but on a build server that is definitely the wrong idea) when you are building.

I understand wanting to use the local package while developing it. If the local package ends up having a change that has not gone through the pull request/review/build process, you are likely to end up needing to wait for that change to be merged in before you can build the code on the build server anyway, so if you are doing continuous builds you may up being unable to push your changes before the package has had its changes merged without suffering a failed build.