How to action warning received on running SF on .NET solution that uses Directory.Build.props

[chivandikwa]

Ask a question

Please assist with the warning received on running the Software Factory on a .NET solution that uses a Directory.Build.props files, specifically for the target framework. The error is phrased as

Could not determine framework element for project "x.csproj". If you're using a "Directory.Build.props" file, change the project's Target Framework to "(unspecified)".

I am not sure how this is meant to be actioned as making the TargetFramework in the csproj "(unspecified)" would not be valid.

[JonathanLydall]

Hi @chivandikwa,

This warning is saying that it couldn't find a <TargetFramework /> nor a <TargetFrameworks /> element in the .csproj. In most cases this is because a Directory.Build.props file is being used.

Before we propose a possible solution, are you using a Directory.Build.props file in this case, or is there something else going on?

[chivandikwa]

@JonathanLydall Yes, in this case I am using a Directory.Build.props file that sets the TargetFramework solution wide

[JonathanLydall]

Thanks @chivandikwa,

I suspected as much, what we'll be doing is changing our module to not output a warning here anymore.

At one point our advice was to change a setting for the project in the Visual Studio designer for such scenarios, but that's no longer good practice for other reasons, hence us going to instead remove the warning instead.

We'll let you know when the update to the module is ready.

[JonathanLydall]

Hi @chivandikwa,

Version 3.4.1-pre.4 of the Intent.VisualStudio.Projects module now has this warning removed.

We've been thinking about a more comprehensive solution to this where we manage a Directory.Build.props and was wanting to run our thinking by you first.

Our current thinking is to do it in the same way that we are handling Central Package Management (CPM), where in the Visual Studio designer on the root Solution node there will be an option to have centralized Framework settings which are then managed inside a Directory.Build.props which will always be in the same location as the .sln file. Like we do with .csproj files today, for the Directory.Build.props file, we would be as unobtrusive as possible and not change or remove any other settings which may have been added to it.

Then for individual .csproj files in the Visual Studio designer, essentially like CPM, you would have settings as to whether or not it's centrally managed, or overridden.

Do you have any thoughts on this?

[JonathanLydall]

Just to close the loop here for now. We have removed this warning to prevent it getting in the way at all if a Directory.Build.props file is used and have a task on our backlog to add more explicit Directory.Build.props support at some point in the future.

You can watch our monthly "What's new" emails for when this work has been completed and in the meantime we're closing this issue, but please don't hesitate to add further comments or queries should you have any.