Skip to main content

Return to Answer

deleted 1 character in body
Source Link
Luke Girvin
Luke Girvin
  • 13.5k
  • 10
  • 69
  • 87

These are functionally equivalent. With one exception, using attributes on the <PackageReference> element is a shortcut for having a nested elements by the same name. The exception is the Include attribute, which cannot be a nested element.

So, Visual Studio, MSBuild, NuGet, etc. will treat these the the same:

<PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0" /> <PackageReference Include="Contoso.Utility.UsefulStuff"> <Version>3.6.0</Version> </PackageReference>

Same goes for the other attributes like "ExcludeAsset".

after using NuGet package manager (in VS), I ended up with quite different XML though.

The NuGet package manager in VS isn't honoring the original format of the document when it makes modifications to your <PackageReference>'s. It probably NuGet is getting the interprettedinterpreted result of the .csproj file, not the raw XML, so it doesn't know whether you were using attributes or nested elements.

These are functionally equivalent. With one exception, using attributes on the <PackageReference> element is a shortcut for having a nested elements by the same name. The exception is the Include attribute, which cannot be a nested element.

So, Visual Studio, MSBuild, NuGet, etc. will treat these the the same:

<PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0" /> <PackageReference Include="Contoso.Utility.UsefulStuff"> <Version>3.6.0</Version> </PackageReference>

Same goes for the other attributes like "ExcludeAsset".

after using NuGet package manager (in VS), I ended up with quite different XML though.

The NuGet package manager in VS isn't honoring the original format of the document when it makes modifications to your <PackageReference>'s. It probably NuGet is getting the interpretted result of the .csproj file, not the raw XML, so it doesn't know whether you were using attributes or nested elements.

These are functionally equivalent. With one exception, using attributes on the <PackageReference> element is a shortcut for having a nested elements by the same name. The exception is the Include attribute, which cannot be a nested element.

So, Visual Studio, MSBuild, NuGet, etc. will treat these the the same:

<PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0" /> <PackageReference Include="Contoso.Utility.UsefulStuff"> <Version>3.6.0</Version> </PackageReference>

Same goes for the other attributes like "ExcludeAsset".

after using NuGet package manager (in VS), I ended up with quite different XML though.

The NuGet package manager in VS isn't honoring the original format of the document when it makes modifications to your <PackageReference>'s. It probably NuGet is getting the interpreted result of the .csproj file, not the raw XML, so it doesn't know whether you were using attributes or nested elements.

Source Link
natemcmaster
natemcmaster
  • 27k
  • 7
  • 80
  • 100

These are functionally equivalent. With one exception, using attributes on the <PackageReference> element is a shortcut for having a nested elements by the same name. The exception is the Include attribute, which cannot be a nested element.

So, Visual Studio, MSBuild, NuGet, etc. will treat these the the same:

<PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0" /> <PackageReference Include="Contoso.Utility.UsefulStuff"> <Version>3.6.0</Version> </PackageReference>

Same goes for the other attributes like "ExcludeAsset".

after using NuGet package manager (in VS), I ended up with quite different XML though.

The NuGet package manager in VS isn't honoring the original format of the document when it makes modifications to your <PackageReference>'s. It probably NuGet is getting the interpretted result of the .csproj file, not the raw XML, so it doesn't know whether you were using attributes or nested elements.