Question

I just created a custom nuget package with the goal of packaging our Devart dlls s.t. we have a proper versioning and updating mechanism in place throughout all of our projects.

The structure of the Nuget package is according to the instructions on the offical wiki and looks as follows:

• DevartOracle
  • content
    • web.config.transform
  • lib
    • Devart.Data.Oracle.dll
    • …
  • DevartOracle.nuspec

The content of the nuspec file is more or less the following:

<?xml version="1.0"?>
<package >
  <metadata>
    <id>DevartOracle</id>
    <version>6.70.311-pre6</version>
    <title>Devart Oracle dotConnect</title>
    ...
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Drivers from Devart for Oracle and Entity Framework</description>
    <releaseNotes></releaseNotes>
    <copyright>Copyright 2012</copyright>
    <tags></tags>
    <dependencies>
    </dependencies>
  </metadata>
</package>

Nothing special actually. I publish the nuget package to our local repository using the following command:

nuget pack DevartOracle.nuspec

The dll’s install just fine, however I also wanted to create a web.config merge. So I added a web.config.transform file as specified in the docs…again with the following content:

 <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity name="Devart.Data.Oracle" publicKeyToken="09af7300eec23701" culture="neutral" />
          <bindingRedirect oldVersion="0.0.0.0-6.70.311.0" newVersion="6.70.311.0" />
        </dependentAssembly>
      </assemblyBinding>
    </runtime>
    <system.data>
      <DbProviderFactories>
        <remove invariant="Devart.Data.Oracle" />
        <add name="dotConnect for Oracle" invariant="Devart.Data.Oracle" description="Devart dotConnect for Oracle" type="Devart.Data.Oracle.OracleProviderFactory, Devart.Data.Oracle, Version=6.70.311.0, Culture=neutral, PublicKeyToken=09af7300eec23701" />
      </DbProviderFactories>
    </system.data>
  </configuration>

The Problem

When I execute the merge into a web.config with a non-existent or empty <assemblyBinding> section everything works as expected, however when I have – say – the follwing content already there:

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="EntityFramework" publicKeyToken="b77a5c561934e089" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

then the result of the merge is this odd one:

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="EntityFramework" publicKeyToken="b77a5c561934e089" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
      <assemblyIdentity name="Devart.Data.Oracle" publicKeyToken="09af7300eec23701" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-6.70.311.0" newVersion="6.70.311.0" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

Any ideas??

---

Update:

A Microsoft employee and active NuGet developer posted an update on Twitter which might be worth sharing here as info:
https://twitter.com/dotnetjunky/status/266533404143656960

Answer 1

By design, NuGet only allows to append changes to an existing XML file (merge works for any file of type XML, no matter what extension, as long as your file to merge is named using the convention of {filename}.{extension}.transform).

This is because NuGet also needs to be able to uninstall the changes made by a package installation (unless you manually made modifications to the changed file after installation, in which case NuGet will leave it untouched upon uninstall).

This is very different from what you expect from XML Config Transforms which is probably causing the confusion here.

If you want real transformations on the target file, you’ll have to go the PowerShell route and do so by scripting an install.ps1 and uninstall.ps1 file within the package’s tools folder.