Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NET project file not updated #2218

Open
pascalberger opened this issue Nov 7, 2018 · 36 comments
Open

.NET project file not updated #2218

pascalberger opened this issue Nov 7, 2018 · 36 comments
Labels
L: dotnet:nuget NuGet packages via nuget or dotnet T: bug 🐞 Something isn't working

Comments

@pascalberger
Copy link

While packages.config file was updated the csproj file was not updated in this PR: https://github.com/bbtsoftware/TfsUrlParser/pull/25/files

@feelepxyz
Copy link
Contributor

@pascalberger hey sorry for the incredibly slow response on this! Is this still an issue for you? Looks like you've removed your packages file?

@pascalberger
Copy link
Author

@feelepxyz The error still occurs from time to time on projects with packages.config

@justalemon
Copy link

I can also confirm this on justalemon/GGOV#16. Had to fix the csproj manually.

You can see how bad this is by taking a look at the respective AppVeyor build.

@feelepxyz
Copy link
Contributor

Sorry, just realised this is a known issue and @greysteil already got back to you on it! To fix this issue is unfortunately a pretty major piece of work so won't get to any time soon :((

We're hopefully getting some resource to work on this in the next few months.

@justalemon
Copy link

Hi, there has been any progress on this?

cc @feelepxyz

@greysteil
Copy link
Contributor

Sorry for the wait on this one - we're doing some infrastructure work that has taken up all of my time.

The change required here isn't trivial, as Phil says, so it's not something I can promise we'll get to immediately, but I'd really like to have it fixed. I'm hoping we'll have some .NET expertise on the team in the relatively near future, which will mean we can power through this and a couple of other issues 🤞.

@caiofbpa
Copy link

caiofbpa commented Apr 5, 2019

I'm having this issue too, and I don't understand why this isn't a trivial change.

In projects that have only the .csproj files, mostly .NET Standard projects, dependabot updates the version number accordingly.

In projects with package.config files, dependabot updates the version number too, it just needs to do the same on the .csproj too. I'm assuming the logic is already there, it just needs to be called appropriately.

@justalemon
Copy link

.csproj is just XML, so there is not a lot to do other than search for an ItemGroup that contains a Reference where Include starts with the package name(ish).

@greysteil
Copy link
Contributor

Just digging into this now - looks like the issues described here are quite separate.

@justalemon - it looks like in justalemon/GGOV#16 Dependabot missed your ...csproj declaration because you use Reference, rather than PackageReference, as the tag name. I couldn't find any docs on that - could you point me to some? As you can see, that isn't included in Dependabot's selector.

@pascalberger - it looks like the issue on your repo is from a very old PR, and you've re-organised your project since. Do you have a more recent example of the issue on one of your repos?

@caiofbpa - can you link to a PR where you've seen this problem and I'll dig into that?

@caiofbpa
Copy link

caiofbpa commented Apr 9, 2019

@greysteil thanks for taking the time to look into this.

We only use dependabot in private projects, but assuming you can look into dependabot's logs for a specific PR, here it is: https://github.com/mercos/offline/pull/1965

Dependabot should have also edited the .csproj file replacing 1.3.4 to 2.1.0 in the line where Refractored.FloatingActionButton is present. Currently I have to do that manually, so I'm opening a different PR for that.

@pascalberger
Copy link
Author

@greysteil Here's a newer one: cake-contrib/Cake.Issues.Reporting.Generic#148. For this project and package everytime only packages.config is updated and csproj not.

@justalemon
Copy link

@greysteil This is not documented for some reason. All of my .NET Framework projects have Reference instead of PackageReference. The same applies for @pascalberger Cake.Issues.Reporting.Generic.

@RohanNagar
Copy link

RohanNagar commented Apr 9, 2019

I believe Reference is used for assembly references. In your case @justalemon, your packages.confg is the "PackageReference" equivalent, and the binaries are downloaded from the Nuget feed into your local machine. Then, in the csproj since you already have the assemblies on the machine, it uses Reference to reference the assembly directly.

In other words, using PackageReference in a csproj is a direct reference to a nuget package. But if you have a packages.config, that takes the place of the nuget package reference, so you need to use Reference to reference the assembly that was downloaded from the packages.config declaration.

I'm not sure why I can't find great documentation on this, but it is standard. I have a project where I directly use Reference to a local dll assembly.

Edit: Take a look at this (https://docs.microsoft.com/en-us/aspnet/web-forms/overview/deployment/web-deployment-in-the-enterprise/understanding-the-project-file#items-and-item-groups):

... the Reference list includes assemblies that must be in place for a successful build, the Compile list includes code files that must be compiled, and the Content list includes resources that must be copied unaltered.

@greysteil
Copy link
Contributor

Got you. @caiofbpa, in your case it looks like it's a HintPath that's part of a reference that hasn't been updated, so all of these are connected.

I think Dependabot should be able to successfully update these references whilst continuing to use its current regex-based approach for .NET. We'll need new logic for finding and updating them as they're structured differently, but I think this is still just a straight find and replace for the version in the relevant blocks. Make sense?

@caiofbpa
Copy link

@greysteil Makes total sense, it should simply be a find and replace indeed.

Sometimes one dependency triggers updates on others, but that is an exception that only happens on old projects (which is my case) and shouldn't be a concern because with .NET Core this has changed and is no longer an issue. I can treat those cases manually here, the find and replace is enough for most cases.

@caiofbpa
Copy link

@greysteil Sorry to be possibly annoying, but do you have any news about this? It sounded like a quick and simple solution to a problem that is making dependabot quite unusable for some .NET projects.

@adamralph
Copy link

Would it be better to spend energy on switching to the new csproj rather than getting issues like this fixed?

@caiofbpa
Copy link

Everyone using Xamarin is stuck with Mono-like csproj for at least one project. It's not really my choice.

@pascalberger
Copy link
Author

Would it be better to spend energy on switching to the new csproj rather than getting issues like this fixed?

I can't speak about what priorities Dependabot has, what resources are available and how much effort it is to fix this. But to say, for me this is not a critical issue. I can live with current restrictions for cases where I cannot switch to the new csproj format. Although there aren't many on my side and situation might be different for other people.

@greysteil
Copy link
Contributor

Sorry for the slow progress on this one - it's not lack of willing. The GitHub acquisition announced on Thursday has been in the works for the last couple of months, so I haven't had as much time for issues like this as I would like.

I'm going to take a look at this now and see if I can get it done.

@caiofbpa
Copy link

@greysteil no problem at all! Congratulations on the acquisition, this is wonderful news for us, doubling the team means faster improvements and expanded support for other languages. Thanks for your solicitude and keep up the good work! If you need any more info, just ask. 😄 👏

@ronaldbarendse
Copy link

There's more at play here when using the old .csproj format with a packages.config file, besides updating the version in packages.config:

  • Existing references must be updated
  • New references must be added (if the new version includes a new assembly/.dll) or removed
  • Build targets/properties must be updated
  • Uninstall/install (XDT) config transforms must be handled
  • Content must be added to the project file (with the appropriate build action)
  • Custom install.ps1 scripts must be run (possibly requiring user input?)
  • Probably lots of other stuff...

A lot has changed in the new csproj-format when using PackageReference, most of them to address these issues...

@twalsh92
Copy link

twalsh92 commented Jul 2, 2019

Is there any update on this, as I'm currently hitting issues with dependabot not updating the project files?

@greysteil
Copy link
Contributor

Not yet. If you link to some PRs that are incorrect from here it will help us build fixtures when we fix, though.

@3F
Copy link

3F commented Jul 3, 2019

Please note the following features with .NET projects:

new references records

Some updates may add new references in project files if we're talking about nuget manager.

For example, for projects below, the following direct reference are not needed. But NuGet dependency policy will add this anyway:

  • Cecil 0.10.3 to 0.10.4 (same case as for my link to PR above):
diff --git "a/NSBin/NSBin.csproj" "b/NSBin/NSBin.csproj"
index b46d601..8beb9c1 100644
--- "a/NSBin/NSBin.csproj"
+++ "b/NSBin/NSBin.csproj"
@@ -39,8 +39,17 @@
     <AssemblyOriginatorKeyFile>key.snk</AssemblyOriginatorKeyFile>
   </PropertyGroup>
   <ItemGroup>
-    <Reference Include="Mono.Cecil, Version=0.10.3.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e, processorArchitecture=MSIL">
-      <HintPath>..\packages\Mono.Cecil.0.10.3\lib\net40\Mono.Cecil.dll</HintPath>
+    <Reference Include="Mono.Cecil, Version=0.10.4.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e, processorArchitecture=MSIL">
+      <HintPath>..\packages\Mono.Cecil.0.10.4\lib\net40\Mono.Cecil.dll</HintPath>
+    </Reference>
+    <Reference Include="Mono.Cecil.Mdb, Version=0.10.4.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e, processorArchitecture=MSIL">
+      <HintPath>..\packages\Mono.Cecil.0.10.4\lib\net40\Mono.Cecil.Mdb.dll</HintPath>
+    </Reference>
+    <Reference Include="Mono.Cecil.Pdb, Version=0.10.4.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e, processorArchitecture=MSIL">
+      <HintPath>..\packages\Mono.Cecil.0.10.4\lib\net40\Mono.Cecil.Pdb.dll</HintPath>
+    </Reference>
+    <Reference Include="Mono.Cecil.Rocks, Version=0.10.4.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e, processorArchitecture=MSIL">
+      <HintPath>..\packages\Mono.Cecil.0.10.4\lib\net40\Mono.Cecil.Rocks.dll</HintPath>
     </Reference>
     <Reference Include="System" />
     <Reference Include="System.Core" />
  • Microsoft.VisualStudio.Shell.15.0.15.9.28307 to 16.1.28917.181
diff --git "a/vsSolutionBuildEvent/vsSolutionBuildEvent.csproj" "b/vsSolutionBuildEvent/vsSolutionBuildEvent.csproj"
index 9d43f91b..fdddf368 100644
--- "a/vsSolutionBuildEvent/vsSolutionBuildEvent.csproj"
+++ "b/vsSolutionBuildEvent/vsSolutionBuildEvent.csproj"
@@ -150,7 +150,18 @@
     <Reference Include="System.Design" />
     <Reference Include="System.Drawing" />
     <Reference Include="System.Management" />
+    <Reference Include="System.Security.Cryptography.X509Certificates, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
+      <HintPath>..\packages\System.Security.Cryptography.X509Certificates.4.3.0\lib\net461\System.Security.Cryptography.X509Certificates.dll</HintPath>
+      <Private>True</Private>
+      <Private>True</Private>
+    </Reference>
     <Reference Include="System.ServiceModel" />
+    <Reference Include="System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
+      <HintPath>..\packages\System.Threading.Tasks.Extensions.4.5.2\lib\netstandard2.0\System.Threading.Tasks.Extensions.dll</HintPath>
+    </Reference>
+    <Reference Include="System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
+      <HintPath>..\packages\System.ValueTuple.4.5.0\lib\net47\System.ValueTuple.dll</HintPath>
+    </Reference>
     <Reference Include="System.Xaml" />
     <Reference Include="System.Xml" />
@@ -174,12 +185,6 @@
           <HintPath>..\packages\Microsoft.VisualStudio.OLE.Interop.7.10.6071\lib\Microsoft.VisualStudio.OLE.Interop.dll</HintPath>
           <Private>True</Private>
         </Reference>
-        <Reference Include="Microsoft.VisualStudio.Shell.15.0, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
-          <HintPath>..\packages\Microsoft.VisualStudio.Shell.15.0.15.9.28307\lib\net45\Microsoft.VisualStudio.Shell.15.0.dll</HintPath>
-        </Reference>
-        <Reference Include="Microsoft.VisualStudio.Shell.Framework, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
-          <HintPath>..\packages\Microsoft.VisualStudio.Shell.Framework.15.9.28307\lib\net45\Microsoft.VisualStudio.Shell.Framework.dll</HintPath>
-        </Reference>
         <Reference Include="Microsoft.VisualStudio.Shell.Interop, Version=7.1.40304.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
           <HintPath>..\packages\Microsoft.VisualStudio.Shell.Interop.7.10.6072\lib\net11\Microsoft.VisualStudio.Shell.Interop.dll</HintPath>
           <Private>True</Private>

....
+ more than 100 lines of other new added changes for new references

Choose/When

Moreover, some of this may use Choose/When: https://github.com/3F/vsSolutionBuildEvent/blob/c68aea2794ec70fde43ddbe77fd9a185fa6429f0/vsSolutionBuildEvent/vsSolutionBuildEvent.csproj#L165-L170

  <Choose>
    <!-- SDK15+ -->
    <When Condition="$(DefineConstants.Contains('VSSDK_15_AND_NEW'))">
      <ItemGroup>
        <Reference Include="Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\Microsoft.Build.Framework.15.9.20\lib\net46\Microsoft.Build.Framework.dll</HintPath>

Even local updating via nuget works incorrect at all (see vsSolutionBuildEvent). So I don't know about dependabot.

Analyzer

Also please don't forget about Analyzer records:

https://github.com/3F/vsSolutionBuildEvent/blob/c68aea2794ec70fde43ddbe77fd9a185fa6429f0/vsSolutionBuildEvent/vsSolutionBuildEvent.csproj#L824-L829

    <When Condition="$(DefineConstants.Contains('VSSDK_15_AND_NEW'))">
      <ItemGroup>
        <Analyzer Include="..\packages\Microsoft.VisualStudio.SDK.Analyzers.15.7.4\analyzers\cs\Microsoft.VisualStudio.SDK.Analyzers.dll" />
        <Analyzer Include="..\packages\Microsoft.VisualStudio.Threading.Analyzers.15.8.209\analyzers\cs\Microsoft.VisualStudio.Threading.Analyzers.CodeFixes.dll" />
        <Analyzer Include="..\packages\Microsoft.VisualStudio.Threading.Analyzers.15.8.209\analyzers\cs\Microsoft.VisualStudio.Threading.Analyzers.dll" />
</ItemGroup>

Hope this can help isolate the problem. Thanks!

3F referenced this issue in 3F/vsSolutionBuildEvent Aug 10, 2019
…bot/feedback/issues/259

* Updated `Moq 4.12.0`. Closes #47
* Updated `Microsoft.Build.Framework 16.0.461`. Closes #46
* Updated `Microsoft.VisualStudio.SDK.Analyzers 16.3.2`
* Updated `Microsoft.VisualStudio.SDK.EmbedInteropTypes 15.0.27`
* Updated `Microsoft.VisualStudio.Threading 16.3.13`. Closes #51
* Updated `Microsoft.VisualStudio.Threading.Analyzers 16.3.13`
* Updated `Microsoft.VisualStudio.Utilities 16.2.29122.156`
* Updated `Newtonsoft.Json 12.0.2`. Closes #50
* Updated `NLog 4.6.6`. Closes #52
* Updated `StreamJsonRpc 2.1.55`. Closes #49

* Ignored `Microsoft.VisualStudio.Shell.15.0`. Closes #48 (read details there)
* Ignored `Microsoft.VisualStudio.Shell.Framework`. Related to #48.

Also updates just released MvsSln 2.4:
https://github.com/3F/MvsSln/releases/tag/v2.4
@3F
Copy link

3F commented Sep 1, 2019

I don't know... for .NET packages dependabot adds more inconvenience than improvements because I need to fix manually each PR for more than 40+ packages in each .NET based projects.

just again, today:
3F/vsSolutionBuildEvent#58
3F/vsSolutionBuildEvent#57

Seems like I will disable .NET feature because it's hard :( Hope this will be fixed someday.

By the way, I also don't like control via .dependabot/config.yml (maybe because of this issue) but today this is the only way to add some ignored_updates. Or I just can't find something in your online app.dependabot.com

@greysteil
Copy link
Contributor

Sorry to hear that but I would definitely disable in your case. Sadly we just don't have the resource to make the improvements that we'd like to at the moment - we're very happy to accept pull requests for them.

@3F
Copy link

3F commented Sep 2, 2019

I see. Same story for me. This is why this project looks great to save a bit of time. Thanks for this!

I have no time today but I'll try to consider later some PR to dependabot if it will be still an unresolved problem.

@caiofbpa
Copy link

caiofbpa commented Sep 2, 2019

@3F I use dependabot as a reminder of which libraries have new versions, and then I go and manually update them together. Dependabot closes the dependency PRs as soon as it detects that I updated manually. It's been very useful to me that way, I don't have to keep checking for updates manually on all projects.

@3F
Copy link

3F commented Sep 2, 2019

@caiofbpa

I use dependabot as a reminder

For some cases it must be a good idea. However, some projects may contain many references that's in *regular updates ie. cyclical update at the same time together with. This simply adds more unrelated tasks for your timeline.

then I go and manually update them together

The problem is that some dependencies such as VSSDK may expose too much "unrelated" opened PR. I can restrict it to 1 of course but it's more like I still need to check it and fix it manually for all others.

For example, yes, just one commit closes lot of dependabot's PRs:

3F/vsSolutionBuildEvent@e50775c

but ...

@caiofbpa
Copy link

stalebot just reminded me about this.

Just chiming in to let you all know that I don't need this anymore. We managed to convert our .csproj from using package.config to using PackageReference (more info here). This made dependabot work like a charm for all our .NET projects.

Thanks for the hard work!

@bording
Copy link
Contributor

bording commented Feb 4, 2020

Given the complexity of properly updating a project that uses packages.config, I'd much prefer that you disable your arguably broken support for packages.config until you're able to get it working properly.

Right now Dependabot creates incorrect PRs for these projects, so they will never be mergeable. This just makes the PRs noise that I have to sort through.

@infin8x infin8x transferred this issue from dependabot/feedback Jun 29, 2020
@infin8x infin8x added L: dotnet:nuget NuGet packages via nuget or dotnet T: bug 🐞 Something isn't working labels Jul 2, 2020
@jeffwidman
Copy link
Member

jeffwidman commented Sep 17, 2022

Re: the noise... for those who aren't aware it is possible to disable security updates or version updates.

As far as fixing the root cause, I'm afraid we probably won't get to this one for a while. If anyone has interest and wants to take a crack at it, we'd happily provide suggestions on where to start and review a PR.

@dependabot dependabot deleted a comment from stale bot Feb 6, 2023
@marco-carvalho
Copy link

really miss this feature 😢

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
L: dotnet:nuget NuGet packages via nuget or dotnet T: bug 🐞 Something isn't working
Projects
None yet
Development

No branches or pull requests