Remove assembly references that point to files within a custom nuget packages folder

[mungojam]

I'm going to have a look at this myself now. It might involve referencing nuget in order to apply the nuget.config location and parsing. We set our packages folder in a nuget.config file a few levels up.

[hvanbakel]

You could probably just check if the path contains a folder called packages, both the props and targets would be there. It might not be perfect but it will work for ~95% or more of the cases

…

On Sat, Mar 10, 2018, 08:23 Mark Adamson ***@***.***> wrote: I'm going to have a look at this myself now. It might involve referencing nuget in order to apply the nuget.config location and parsing. We set our packages folder in a nuget.config file a few levels up. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#61>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD8FPB0zy15HfxoP3r6bjx9mUZlCsQJOks5tc_4FgaJpZM4SlVjM> .

[mungojam]

Yeah, that's true. In our case I helpfully named the folder 'Libraries' instead, but maybe I could just change that instead rather than going to lots of effort with nuget client libraries.

Or maybe it could be a command line hint that can be passed in if you know what the packages folder is

[mungojam]

@hvanbakel I've started on it, but it looks like it could be done by applying the existing RemovePackageAssemblyReferencesTransformation after the other transformations have been applied. I was a bit surprised that the transformations are applied in parallel and not serially as a pipeline as I would think that some could benefit from the existing transformations as in this case.

I can submit what I've done anyway and leave it up to you

[hvanbakel]

Sure no problem, if you m can send a PR I'll have a look

…

On Sat, Mar 10, 2018, 09:42 Mark Adamson ***@***.***> wrote: @hvanbakel <https://github.com/hvanbakel> I've started on it, but it looks like it could be done by applying the existing RemovePackageAssemblyReferencesTransformation after the other transformations have been applied. I was a bit surprised that the transformations are applied in parallel and not serially as a pipeline as I would think that some could benefit from the existing transformations as in this case. I can submit what I've done anyway and leave it up to you — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#61 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD8FPGQ8R0CEkfPeUraq5pqRQ79oIZRpks5tdBB-gaJpZM4SlVjM> .

[mungojam]

I'll have more of a play. I see now that AssemblyReferenceTransformation.RemoveExtraAssemblyReferences is applied after the other transformations. I expect that was just missing our packages folder because it is called Libraries.

So perhaps the only change I will make is to apply the same fix for targets. One for tomorrow or next week now though.

[hvanbakel]

Is this still an issue?

[mungojam]

I suspect there are two issues, one is that maybe targets aren't picked up and the other is the assumption on 'packages' folder. I'm going to have a go at solving the 'packages' folder one this evening.

[hvanbakel]

So in the new style, the targets no longer live in the csproj. I found that out this week. They go into the obj folder which has a generated targets file that includes all the targets from packages. So I guess we shouldn't copy targets at all then.

…

On Sun, Mar 18, 2018, 10:35 Mark Adamson ***@***.***> wrote: I suspect there are two issues, one is that maybe targets aren't picked up and the other is the assumption on 'packages' folder. I'm going to have a go at solving the 'packages' folder one this evening. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#61 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD8FPFNsK5T_sMdKjK7dsCH1Pxgchobhks5tfpr1gaJpZM4SlVjM> .

[mungojam]

That's right yeah, the same as for AssemblyReferences and so the treatment should be the same for both. You want to leave open the possibility that somebody has manually added some targets from somewhere else so only to remove those that have clearly come from packages.

[mungojam]

I've restricted this issue now to just cover the custom nuget packages folder. About to submit pull request. I'll raise a separate one for targets