Restoring results in obscure error: Invalid framework identifier ''

[neeraj9]

Details about Problem

I am trying to build one of the project for Linux operating system and it fails with the .NET SDK 5.0. My main concern is about the obscure error message displayed which does not give any indication of the project file (csproj) or the target framework which is the source of issue here.

$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.101
 Commit:    d05174dc5a

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  20.04
 OS Platform: Linux
 RID:         ubuntu.20.04-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.101/

Host (useful for support):
  Version: 5.0.1
  Commit:  b02e13abab

.NET SDKs installed:
  5.0.101 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

It is probably this https://github.com/NuGet/NuGet.Client/blob/release-5.8.x/src/NuGet.Core/NuGet.Frameworks/NuGetFramework.cs#L260 which is the source of issue. It doesn't give the current project file being processed or what was the string present as part of the target framework. It is a source of concern since it becomes much harder to debug such issues for big projects.

Did not work ever for my project.

Detailed repro steps so we can see the same problem

Restoration of the project via "dotnet restore" fails with obscure message.

     2>/usr/share/dotnet/sdk/5.0.101/NuGet.targets(131,5): error : Invalid framework identifier ''. [/home/neeraj/someproj/build.proj]
         NuGet.Frameworks.FrameworkException: Invalid framework identifier ''.
            at NuGet.Frameworks.NuGetFramework.GetShortFolderName(IFrameworkNameProvider mappings)
            at NuGet.Frameworks.NuGetFramework.GetShortFolderName()
            at NuGet.Commands.MSBuildRestoreUtility.<>c__DisplayClass6_0.<GetPackageSpec>b__0(TargetFrameworkInformation tfi)
            at NuGet.Shared.Extensions.ForEach[T](IEnumerable`1 enumeration, Action`1 action)
            at NuGet.Commands.MSBuildRestoreUtility.GetPackageSpec(IEnumerable`1 items)
            at System.Linq.Enumerable.SelectEnumerableIterator`2.MoveNext()
            at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
            at NuGet.Commands.MSBuildRestoreUtility.GetDependencySpec(IEnumerable`1 items)
            at NuGet.Build.Tasks.RestoreTask.ExecuteAsync(ILogger log)
       Done executing task "RestoreTask" -- FAILED.

Sample Project

Its a proprietary project, so cannot provide the code here.

[neeraj9]

I noticed that the issue https://github.com/NuGet/Home/issues/5413 also talks about something similar, although not sure if that is exactly the same thing.

It will be great to get working steps to help debug the issue further in the interim.

• I have tried searching for TargetFramework within all csproj to ensure correct values.
• Verified that multiple frameworks are not specified (separated with semicolon) within TargetFramework, because then we should be using TargetFrameworks (ending with "s") instead.

[nkolev92]

@neeraj9

NuGet uses the project file for restore and not the code, any chance you can provide us a slimmed down version of your project? Removing all PackageReference and ProjectReference elements should be fine, we only really need to know the value of ~7 properties.

Such as: TargetFramework(s) TargetFrameworkMoniker TargetPlatformMoniker

[nkolev92]

Thank you reporting this issue. At this point we do not have enough information to continue investigating the issue. Please feel free to comment or open a new issue if needed.

[markmcgookin]

I'm getting this myself on macOS and on my linux containers... I can't figure out what is missing. I have dotnet SDK installed 5.0.201 and Runtime 5.0.4. I can build and run a solution fine and debug an app... but when I go to the project directory specifically and do dotnet publish -c Release -o out I get

/usr/local/share/dotnet/sdk/5.0.201/NuGet.targets(131,5): error : Invalid framework identifier ''. [/Users/markmcgookin/work/my-project/API/my-project.csproj]

Obviously I have a mistake somewhere... but there's no help, as if I do dotnet new webapp then the same command it works. I have <TargetFramework>net5.0</TargetFramework> in the csproj file as well.

EDIT: I figured it out... for our scenario anyway. We had the following in some class libraries... which obviously negates it from being processed when in Release.. this removing the 'TargetFramework' from nuget's visibility. Removing the condition sorts it out. User error on this one.

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
        <TargetFramework>net5.0</TargetFramework>

[anoftc]

Hi all

I confirm this error reason. The restore part of "dotnet build" fails with error message error : Invalid framework identifier '' if there is no applicable TargetFramework parts in the csproj file. I can understand the error, but the error message should be improved, that is for sure...

Edit: at least the offending CSPROJ file should be included in the error message, because referencing the SLN means nothing....

With bad csproj contents:

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <TargetFramework>net5.0-windows</TargetFramework>
    <OutputType>WinExe</OutputType>
    <UseWPF>true</UseWPF>

C:\Program Files\dotnet\sdk\5.0.104\NuGet.targets(131,5): error : Invalid framework identifier ''. [c:\_GIT\oenik_prog4hf_2021_1_xxxxxx\PizzaFactory\OENIK_PROG3_2020_2_xxxxxx\OENIK_PROG3_2020_2_xxxxxx.sln]

With good csproj contents:

  <PropertyGroup>
    <TargetFramework>net5.0-windows</TargetFramework>
    <OutputType>WinExe</OutputType>
    <UseWPF>true</UseWPF>

Build succeeded.
    0 Warning(s)
    0 Error(s)

@markmcgookin thanks for the idea!

[tacitfirefox]

I am also getting this when attempting to set up a new code repository. The project file is blank, as the TargetFramework attribute was moved into a directory.build.props file that's supposed to apply to all csproj files in the same folder.

Folder structure is: /solutionDir/directory.build.props /solutionDir/source/directory.build.props: contains an directive. /solutionDir/source/projectDir/my.csproj: only has , no code files yet.

Everything builds fine locally in Visual Studio (no errors, warnings, or messages). However, the restore in the GitHub action fails.

I thought maybe adding a code file to the project would be helpful (just a hunch). Unfortunately, it did not solve the issue. However, moving the TargetFramework attribute out of the directory.build.props file back into the .csproj file seems to have solved the issue.

I'd prefer to not have to define the TargetFramework in every .csproj, but if that's what I have to do going forward, that's fine I guess. It'd be a bit nicer to be able to define that attribute in a props file, in my opinion.

[radutomy]

Pretty much the same problem as @tacitfirefox. Solution builds fine locally in Visual Studio but fails in Azure DevOps. What's the point of a directory.build.props if we have to define TargetFramework in every .csproj

[zivkan]

My steps:

1. mkdir dbpTest | cd
2. dotnet new console
3. cp dvpTest.csproj Directory.Build.props
4. edit dvpTest.csproj to remove the <TargetFramework>net5.0</TargetFramework>
5. edit Directory.Build.props to remove the Sdk="Microsoft.NET.Sdk" and <OutputType>Exe</OutputType>
6. dotnet build

This worked for me.

My issue with MSBuild is that it's a programming language, even though it looks like declarative XML. Like most programming languages, there are more than one way to achieve a single outcome, which basically means boundless complexity and boundless ways errors could be introduced.

If you've never seen it before, I highly recommend Stack Overflow's "How to create a Minimal, Respoducable Example" documentation. It helps explain that people who wish to help can give you much more specific advice if they can see for themselves exactly the error and debug if needed. There are times when we, as people experiencing errors and asking questions, don't know what information is relevant to someone investigating the issue.

In this case, my best guess is that you have a non-SDK style project (one that imports Microsoft.Common.props and Microsoft.CSharp.targets, rather than having that Sdk="Microsoft.NET.Sdk" syntax), but in this case I don't expect dotnet restore or dotnet build to work, even if you add a <TargetFramework> element. But, if you're restoring with msbuild or nuget.exe, then I'd expect it to work without the TargetFramework element.

If you're restoring with nuget.exe, then make sure you're using a newish version, ideally the version that "matches" the version of MSBuild you're using. NuGet's version is 11.0 lower than VIsual Studio and MSBuild. So, NuGet 5.9.x is the version that ships in VS/MSBuild 16.9. In fact, I'd strongly suggest not using nuget.exe at all. I recommend using msbuild -t:restore to restore your solution, or msbuild -t:restore -p:RestorePackagesConfig=true if you have any projects using packages.config. This way you always use the version of NuGet that matches the version of the MSBuild, and you don't need to download nuget.exe in your CI pipeline.

Otherwise, I don't have any other guesses how you're experiencing the errors you're reporting. I'll need a sample project/solution so I can reproduce the error.

[gopalar]

I ran into this issue, when imported project name casing didn't match the actual file name casing.

Incorrect casing

<Project Sdk="Microsoft.NET.Sdk">
    <Import Project="..\Common.service.csproj"/>
</Project>

Correct casing

<Project Sdk="Microsoft.NET.Sdk">
    <Import Project="..\Common.Service.csproj"/>
</Project>

[Joren-Thijs-KasparSolutions]

@tacitfirefox @radutomy I ran into the same issue. Appearently it's a simple matter of case sensitivity between Linux and Windows. The correct file name is Directory.Build.props. I forgot to capitalize the second word causing it to fail on Linux. https://github.com/NuGet/Home/issues/11500#issuecomment-1011033072

[phillip-haydon]

So this bug never got fixed?

[Joren-Thijs-KasparSolutions]

So this bug never got fixed?

So far there is no bug. It's simply a matter of filename casing, which is a user error. Windows is not case sensitive while Linux and MacOS are. Most code in pipelines runs on a Linux agent and so you can run into problems there if you are not carefull about your filenames. An easy way to test for these problems on your windows PC is to try to build and run your solution on WSL2.

Another problem I ran into is when I was building docker containers and forget to copy the Directory.Build.props file into my container.

FROM mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim AS build
WORKDIR /src

COPY nuget.config .
COPY ./*.sln ./
# Copy the Directory.Build.props file so we don't get empty targetframework errors
COPY ./Directory.Build.props ./ 
COPY */*.csproj ./
RUN for file in $(ls *.csproj); do mkdir -p ${file%.*} && mv $file ${file%.*}; **done**

# ... rest of dockerfile

Hope this helps!

[chipplyman]

I ran into this issue when I put a double hyphen inside an xml comment in Directory.Build.props.

Instead of reporting the xml parse failure, nuget silently accepts the broken xml, then fails later down the line.

[yewtechnologiesuk]

Hi All,

I'm getting same error. Please help me to figure out the issue as per the image. My Project settings are as below.

Common Project:

EDI Edifacts Project:

EDI Models Project.

EDI.TestProjects

Regards,

Balwant.

[markmcgookin]

@yewtechnologiesuk At a glance it looks like you are building in Azure DevOps, which I assume will be building in Release mode. Try deleting

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">

and replace with just <PropertyGroup>

That might be the same as my issue above

[yewtechnologiesuk]

Hi Mark,

Thank you very much for prompt solution. It worked. I'm going through some other errors but I will try resolve them first through other inputs.

Regards,

Balwant.

[yimogit]

I encountered the same problem today and found out it was due to Directory The directory referenced in Build.props is not mounted in the container or cannot be found

今天遇到同样的问题，发现是因为 Directory.Build.props 中引用的目录没有挂载到容器中，或找不到，记录一二

[codewing]

Since this is fairly high on the google results: for me the <TargetFramework> was set to NETFramework4.7.2 due to the fact that this was a fairly old project instead of net472... Newer msbuild (17+) versions dont seem to have the issue anymore but 16.10 still had it (at least the msbuild version of mono)

[sbeznebeyev]

So this bug never got fixed?

So far there is no bug. It's simply a matter of filename casing, which is a user error. Windows is not case sensitive while Linux and MacOS are. Most code in pipelines runs on a Linux agent and so you can run into problems there if you are not carefull about your filenames. An easy way to test for these problems on your windows PC is to try to build and run your solution on WSL2.

Another problem I ran into is when I was building docker containers and forget to copy the Directory.Build.props file into my container.

FROM mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim AS build
WORKDIR /src

COPY nuget.config .
COPY ./*.sln ./
# Copy the Directory.Build.props file so we don't get empty targetframework errors
COPY ./Directory.Build.props ./ 
COPY */*.csproj ./
RUN for file in $(ls *.csproj); do mkdir -p ${file%.*} && mv $file ${file%.*}; **done**

# ... rest of dockerfile

Hope this helps!

Exactly, this one COPY ./Directory.Build.props ./ solved my problem

[Nikita-T86]

In my case that error was caused by old Visual Studio and NuGet on Azure DevOps build agent. I have VS 2022 locally and set net6.0-windows;net472 in project file, however on build agent I have VS 2019 that doesn't support .NET 6.0 projects, thats why I had an error about invalid framework identifier there. NuGet also supports .NET 6.0 projects only starting from version 6.0.0.