«

Oct 02

Using nuget.config to control Nuget package reference sources.

Sometimes in software development you have to work around interesting obstacles.

I created a proof-of-concept code working with Cosmos DB. I needed to be able to run this code from my laptop as well as from a VM inside the Azure region. I copied all the code so I could tweak things as needed so the two client connections can behave differently. It was using the Azure Cosmos SDK v3 (3.0.0 to be precise).  https://github.com/Azure/azure-cosmos-dotnet-v3

The challenge came when I noticed the Cosmos Client Options did not contain a way to change the consistency level. That version of the library retrieves the consistency from the Cosmos account. This means there is not a way to choose a lower consistency level than defined in the account.

Thankfully, looking at the latest github link https://github.com/Azure/azure-cosmos-dotnet-v3/blob/master/Microsoft.Azure.Cosmos/src/CosmosClientOptions.cs for the code shows that they have included a public property to set the consistency level. However, that code had not been released to a newer version of that Nuget package. I needed to be able to modify the consistency level on the connection and wasn’t able to wait for their next release.

Choices

I did clone the code to my laptop and was able to compile it. I thought, I could just change the reference in my code from Nuget to an assembly reference. But, the assembly has so many other dependencies and I didn’t want to chase down everyone of them.

So, going back to the Cosmos code, I had it create a Nuget package locally. This works great. With my PoC code I just made another Nuget source to that folder. That worked well, however, that doesn’t work with the code on the Linux VM. It can’t reference a folder on my computer. So, I did this instead.

Custom Nuget Package

I copied the Nuget package to the VM. It now resides in the bin/Debug folder. But, now I had to tell that code where to find the package. Nuget.config to the rescue.

I created a nuget.config file. The existence of the file tells the compiler to leverage it for where and how to retrieve Nuget packages. I added a file source to the bin/Debug folder. This entry was right after the reference to nuget.org. So, now it will attempt to find the packages at nuget.org first. Since it can’t find the locally made one, it looks at the next source in the list. That’s where it found my newly compiled Cosmos library that contains a way to adjust the consistency level.

<configuration>
    <packageSources>
         <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
         <add key="local" value="bin/Debug" />
    </packageSources>
</configuration>

This is the link to the Microsoft documentation on using nuget.config.
https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file

Not only can you control where Nuget packages are pulled from, but you can also add credentials. This is very useful for when pulling from a private Nuget source like in Azure Dev Ops.
In my example, I have a the nuget.org source as well as one called “local”. If that “local” source was actually in Azure Dev Ops I would add credentials like:

    <packageSourceCredentials>
        <local>
            <add key="username" value="some@email.com"/>
            <add key="password" value="..."/>
        </local>
    </packageSourceCredentials>

Notice that the element “local” matches the package source name above.

If using an unencrypted password:

    <packageSourceCredentials>
        <local>
            <add key="username" value="some@email.com"/>
            <add key="ClearTextPassword" value="someExamplePasswordHere!123"/>
        </local>
    </packageSourceCredentials>

Complete file example:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
         <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
         <add key="local" value="bin/Debug" />
         <add key="privateAzureDevOpsSource" value="https://blahblah.com/foo/bar/example" />
    </packageSources>
    <packageSourceCredentials>
        <privateAzureDevOpsSource>
            <add key="username" value="some@email.com"/>
            <add key="ClearTextPassword" value="someExamplePasswordHere!123"/>
        </privateAzureDevOpsSource>
    </packageSourceCredentials>
</configuration>

Conclusion

The point here is that you can take code and make a private Nuget package then make accessible for your needs. The nuget.config file makes that possible.

Update

After seeing that Microsoft did release a new version that included the consistency level option, I did revert to using their latest package version. My custom “fix” was meant to be temporary anyway.

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

hublot replica | replica watches | cartier replica sale | breitling replica sale