3

I'm processing assemblies with Mono.Cecil in a standalone tool. The tool is intended to be framework-neutral (i.e. will load in any .NET 4[.x[.x]] environment] and not have a dependency on e.g. the .NET SDK.

Say I have an assembly containing the following TargetFrameworkAttribute in its IL:

[assembly: TargetFramework(".NETFramework,Version=v4.0", 
   FrameworkDisplayName = ".NET Framework 4")]

What is the correct way to map that to what I believe to be the correct path:-

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0

I'm hoping there's a relatively clean way to manage this from within .NET code.

Is there a standard way to obtain C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework programmatically? Can the obvious subfolder pattern within this be relied on -- i.e. is there any documentation other than this ?

I can see MSBuild via Microsoft.Common.targets and Microsoft.NETFramework.props has quite the warren of 'optimized' logic around this. Even if I was to be willing to shell out to that and e.g. using a Task in there would be too brittle and taking a dependency on discovering the MSBuild tools (v12/4 ...) wouldn't be ideal. Any ideas?

Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
  • There is no clean way, you are trying to recover lost information. Best to focus on a PCL assembly, that's by far the hardest nut to crack. – Hans Passant Dec 11 '13 at 16:57
  • @HansPassant Thanks - I guess the lost info point hits the nail on the head. I agree that PCLs are the correct way to do such neutrality right. Howeever the very mission of the tool in question is to operate on third party assemblies so I do have to confront this issue head on :) (For instance if the assembly I'm processing is a PCL one, I need to derive the associated path too) – Ruben Bartelink Dec 11 '13 at 20:42
  • @RubenBartelink I need to map the same information (basically same scenario as you described). To me it looks like the "FrameworkName" property has information to at least find the reference assembly folder to include in the search path. – Vagaus Mar 14 '14 at 00:59
  • @Vagaus At the point of compilation, all the necessary information is there - the `.targets` files have lots of logic for correctly locating the correct SDK/reference paths. My question pertains to doing this outside of MSBuild, without any other input. I personally solved my problem by forcing the caller to specify a reference path at all times – Ruben Bartelink Mar 14 '14 at 09:51
  • @RubenBartelink I understand. As I said, I have the very same scenario: a tool that changes assemblies. Unfortunately in my case I cannot ask the user to specify the reference path so I am using the information from the TargetFramework to figure out the reference assembly path – Vagaus Mar 14 '14 at 10:51
  • @Vagaus Ah, I missed that point - if you'd said *like the "FrameworkName" property* **of the `TargetFrameworkAttribute`** I'd have realized quicker (property made me think of an MSBuild prop). If you want to resubmit your initial comment we can squash the comment history to make me sound less silly :) – Ruben Bartelink Mar 14 '14 at 12:29
  • It was not clear enough that I was referring to the TargetFrameworkAttribute. What you mean by "resubmit" ? Delete and post again? – Vagaus Mar 14 '14 at 13:03
  • Yep, only if you want though (the time will be wrong but life will go on!) – Ruben Bartelink Mar 14 '14 at 13:17
  • mildly-related: https://stackoverflow.com/questions/57382030/simplest-way-to-build-dotnet-sdk-project-requiring-net461-on-macos – Ruben Bartelink Aug 28 '19 at 08:51

0 Answers0