We are migrating our compilation system to msbuild, and we’ve found that some projects report the following error:
c:srclibsa_libAA.vcxproj : error MSB4057: The target «C» does not exist in the project.
c:srclibsa_libBB.vcxproj : error MSB4057: The target «C» does not exist in the project.
c:srclibsa_libCC.vcxproj : error MSB4057: The target «C» does not exist in the project.
c:srclibsa_libDD.vcxproj : error MSB4057: The target «C» does not exist in the project.
The compilation line is
msbuild "c:srclibsa_liba_lib.sln" /nologo "/target:C" /t:build "/p:Configuration=Release" "/p:Platform=Win32"
As can be seen, the solution has several projects. The project itself exists in the solution and can be compiled from within the VS IDE. Also, other targets do not fail (following the example: A, B, D).
Our previous compilation line worked correctly on the same project:
devenv "c:srclibsa_liba_lib.sln" /project "C" /build /nologo "Release|Win32"
User370409 posted
Hello everybody,
I recently tried to create and test my Xamarin Cross Platform app on my Mac when the following error message appeared:
Description: The target «_CollectBundleResources» does not exist in the project. (MSB4057)
File: Microsoft.Common.CurrentVersion.targets
Project: TestApp.iOS
Path: /Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/msbuild/15.0/bin/Microsoft.Common.CurrentVersion.targets
I programmed my project on Windows. After that I ported the main project + iOS project to my Mac.
Then i tried to rebuild and clean the project, sadly without success.
However, I was able to create and clean up the main project without any problems. The only project i recive this error message from is the iOS one.
BuildOutput-log:
Rebuilding…
TestApp.iOS (Debug|iPhoneSimulator) is being cleaned up
Build started 03.07.2018 10:06:40.
Project «/Users/user1/Transfer/TestApps/iOS App Store release/Test/TestApp.iOS/TestApp.iOS.csproj» (Clean target(s)):
Target GetProjectReferenceTargetFrameworkProperties:
_______________
Project «/Users/user1/Transfer/TestApps/iOS App Store release/Test/TestApp.iOS/TestApp.iOS.csproj» is building «/Users/user1/Transfer/TestApps/iOS App Store release/Test/TestApp/TestApp.csproj» (GetTargetFrameworks target(s)):
Target _CleanAppBundle:
Directory «bin/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/TestApp.iOS.app/» doesn’t exist. Skipping.
Target _CleanDebugSymbols:
Directory «bin/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/TestApp.iOS.app.mSYM» doesn’t exist. Skipping.
Target _CleanDeviceSpecificOutput:
Directory «obj/iPhoneSimulator/Debug/device-builds» doesn’t exist. Skipping.
Directory «bin/iPhoneSimulator/Debug/device-builds» doesn’t exist. Skipping.
Target _CleanIntermediateToolOutput:
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/actool» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/assetpacks» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/codesign» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/coremlc» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/ibtool» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/ibtool-link» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/ibtool-manifests» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/ipa» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/metal» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/optimized» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/scntool» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/TextureAtlas» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/mtouch-cache» doesn’t exist. Skipping.
Directory «obj/iPhoneSimulator/Debug/device-builds/iphone10.3-11.4/» doesn’t exist. Skipping.
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.11
TestApp.iOS (Debug|iPhoneSimulator) is created
Build started 03.07.2018 10:06:41.
Project «/Users/user1/Transfer/TestApps/iOS App Store release/Test/TestApp/TestApp.csproj» (Build target(s)):
Target ResolveAssemblyReferences:
A TargetFramework profile exclusion list will be generated.
Target GenerateTargetFrameworkMonikerAttribute:
Skipping target «GenerateTargetFrameworkMonikerAttribute» because all output files are up-to-date with respect to the input files.
Target CoreXamlG:
Skipping target «CoreXamlG» because it has no inputs.
Target CoreCompile:
Skipping target «CoreCompile» because all output files are up-to-date with respect to the input files.
Target XamlC:
Compiling Xaml
Assembly: obj/Debug/TestApp.dll
ReferencePath: /Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/mscorlib.dll;/Users/user1/Transfer/TestApps/Projects/Test/packages/Newtonsoft.Json.11.0.2/lib/portable-net45+win8+wp8+wpa81/Newtonsoft.Json.dll;/Users/user1/Transfer/TestApps/Projects/Test/packages/Xam.Plugin.DeviceInfo.4.0.0.13/lib/xamarinios10/Plugin.DeviceInfo.dll;/Users/user1/Transfer/TestApps/Projects/Test/packages/sqlite-net-pcl.1.4.118/lib/netstandard1.1/SQLite-net.dll;/Users/user1/Transfer/TestApps/Projects/Test/packages/SQLitePCLRaw.bundle_green.1.1.11/lib/Xamarin.iOS10/SQLitePCLRaw.batteries_green.dll;/Users/user1/Transfer/TestApps/Projects/Test/packages/SQLitePCLRaw.bundle_green.1.1.11/lib/Xamarin.iOS10/SQLitePCLRaw.batteries_v2.dll;/Users/user1/Transfer/TestApps/Projects/Test/packages/SQLitePCLRaw.core.1.1.11/lib/Xamarin.iOS10/SQLitePCLRaw.core.dll;/Users/user1/Projects/Test1/packages/Xamarin.Forms.2.5.0.280555/lib/portable-win+net45+wp80+win81+wpa81/Xamarin.Forms.Core.dll;/Users/user1/Projects/Test1/packages/Xamarin.Forms.2.5.0.280555/lib/portable-win+net45+wp80+win81+wpa81/Xamarin.Forms.Platform.dll;/Users/user1/Projects/Test1/packages/Xamarin.Forms.2.5.0.280555/lib/portable-win+net45+wp80+win81+wpa81/Xamarin.Forms.Xaml.dll;/Users/user1/Transfer/TestApps/Projects/Test/packages/XLabs.Core.2.0.5782/lib/Xamarin.iOS10/XLabs.Core.dll;/Users/user1/Transfer/TestApps/Projects/Test/packages/XLabs.Forms.2.0.5782/lib/Xamarin.iOS10/XLabs.Forms.dll;/Users/user1/Transfer/TestApps/Projects/Test/packages/XLabs.IoC.2.0.5782/lib/portable-net45+netcore45+wp8+MonoAndroid1+MonoTouch1/XLabs.Ioc.dll;/Users/user1/Transfer/TestApps/Projects/Test/packages/XLabs.Platform.2.0.5782/lib/Xamarin.iOS10/XLabs.Platform.dll;/Users/user1/Transfer/TestApps/Projects/Test/packages/XLabs.Serialization.2.0.5782/lib/Xamarin.iOS10/XLabs.Serialization.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/Microsoft.CSharp.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/mscorlib.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Collections.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.ComponentModel.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.ComponentModel.EventBasedAsync.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Core.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Diagnostics.Contracts.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Diagnostics.Debug.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Diagnostics.Tools.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Dynamic.Runtime.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Globalization.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.IO.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Linq.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Linq.Expressions.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Linq.Queryable.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Net.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Net.NetworkInformation.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Net.Primitives.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Net.Requests.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.ObjectModel.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Reflection.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Reflection.Extensions.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Reflection.Primitives.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Resources.ResourceManager.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Runtime.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Runtime.Extensions.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Runtime.InteropServices.WindowsRuntime.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Runtime.Serialization.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Runtime.Serialization.Json.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Runtime.Serialization.Primitives.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Runtime.Serialization.Xml.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Security.Principal.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.ServiceModel.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.ServiceModel.Http.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.ServiceModel.Primitives.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.ServiceModel.Security.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.ServiceModel.Web.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Text.Encoding.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Text.Encoding.Extensions.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Text.RegularExpressions.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Threading.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Threading.Tasks.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Windows.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Xml.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Xml.Linq.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Xml.ReaderWriter.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Xml.Serialization.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Xml.XDocument.dll;/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile/Profile78/System.Xml.XmlSerializer.dll
Module: TestApp.dll
No compiled resources. Skipping writing assembly.
Target CopyFilesMarkedCopyLocal:
Touching «/Users/user1/Transfer/TestApps/iOS App Store release/Test/TestApp/obj/Debug/TestApp.csproj.CopyComplete».
Target _CopyAppConfigFile:
Skipping target «CopyAppConfigFile» because all output files are up-to-date with respect to the input files.
Target CopyFilesToOutputDirectory:
TestApp -> /Users/user1/Transfer/TestApps/iOS App Store release/Test/TestApp/bin/Debug/TestApp.dll
Project «/Users/user1/Transfer/TestApps/iOS App Store release/Test/TestApp.iOS/TestApp.iOS.csproj» (Build target(s)):
/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/msbuild/15.0/bin/Microsoft.Common.CurrentVersion.targets(802,7): error MSB4057: The target «_CollectBundleResources» does not exist in the project.
Done building project «TestApp.iOS.csproj» — FAILED.
Build FAILED.
/Library/Frameworks/Mono.framework/Versions/5.10.1/lib/mono/msbuild/15.0/bin/Microsoft.Common.CurrentVersion.targets(802,7): error MSB4057: The target «_CollectBundleResources» does not exist in the project.
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.75
——————— Done ———————
Build: 1 Error(s), 0 Warning(s)
if you need any further information, just let me know.
Thanks in advance,
Mark Adelhelm
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
Open
bording opened this issue
Apr 11, 2019
· 21 comments
Comments
There is a problem with solution dependencies that I believe was introduced with MSBuild 15.9, and is also a problem with 16.0.
The following scenario causes the problem;
- There is a project that has
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>set - It has a solution dependency on a second project, and that project is multi-targeted.
Steps to reproduce
Build the attached project with MSBuild.exe or dotnet build: GetTargetPathRepro.zip
Expected behavior
The solution should compile without errors.
Actual behavior
The following error occurs:
"C:UsersBrandonsourcereposGetTargetPathReproGetTargetPathRepro.sln" (default target) (1:2) ->
"C:UsersBrandonsourcereposGetTargetPathReproClassLibrary1ClassLibrary1.csproj.metaproj" (default target) (4) ->
"C:UsersBrandonsourcereposGetTargetPathReproClassLibrary1ClassLibrary1.csproj" (default target) (2:6) ->
"C:UsersBrandonsourcereposGetTargetPathReproClassLibrary1ClassLibrary1.csproj" (_GetFrameworkAssemblyReferences target) (2:10) ->
"C:UsersBrandonsourcereposGetTargetPathReproClassLibrary2ClassLibrary2.csproj" (GetTargetPath target) (3:15) ->
C:UsersBrandonsourcereposGetTargetPathReproClassLibrary2ClassLibrary2.csproj : error MSB4057: The target "GetTargetPath" does not exist in the project.
0 Warning(s)
1 Error(s)
Environment data
It repros with MSBuild 15.9.21.664 and 16.0.461.62831.
It also repros with .NET Core SDK 2.2.106 and 3.0.100-preview3-010431
I believe it worked fine before MSBuild 15.9, but I don’t know an exact version.
This is fairly involved. It’s related to 3258497, which was in 15.8.
NuGet packaging calls _GetFrameworkAssemblyReferences which builds the current project (ClassLibrary1) with a specified TargetFramework and BuildProjectReferences = false. That is a distinct build from the «real» build of that project, so it creates a new project instance. That instance then tries to ResolveProjectReferences, which fails because when BuildProjectReferences != true, it calls GetTargetPath instead of the default target. That then fails, because GetTargetPath isn’t defined for the outer build of a multitargeted project.
I think NuGet should special case the GeneratePackageOnBuild case for a single-targeted project to collapse to the current build, which already has references resolved.
This can be worked around by adding a Directory.Build.props for your solution with this property:
<Project> <PropertyGroup> <AddSyntheticProjectReferencesForSolutionDependencies>false</AddSyntheticProjectReferencesForSolutionDependencies> </PropertyGroup> </Project>
Since building from Visual Studio seems work fine and not result in an error, I assume that’s because it has a different way of invoking all of this?
This can be worked around by adding a Directory.Build.props for your solution with this property:
The workaround I came up with that seems to be working was to switch to a ProjectReference with
ReferenceOutputAssembly="false" and PrivateAssets="All" set.
I think NuGet should special case the GeneratePackageOnBuild case for a single-targeted project to collapse to the current build, which already has references resolved.
I could be misunderstanding what you’re saying here, but the problem still occurs when ClassLibrary1 is multi-targeted a well.
Since building from Visual Studio seems work fine and not result in an error, I assume that’s because it has a different way of invoking all of this?
Yes, unfortunately. VS builds projects in a solution using a pretty different mechanism from MSBuild’s solution handling.
The workaround I came up with that seems to be working was to switch to a
ProjectReferencewith
ReferenceOutputAssembly="false"andPrivateAssets="All"set.
Yeah, if that works for you I’d prefer it over a solution dependency—it’s clearer from the MSBuild side.
FWIW, I had 2 references to the same project within the solution. Opening the csproj file with a text editor indicated that (Visual Studio did not, neither did a ‘remove project reference’ > ‘add project reference’).
The 2 references had different guids, 1 of them was the incorrect one.
I had the same error and somewhat similar to @sebashek, I had two identical project references listed in a single project file. Removing one of the references fixed the issue.
micahosborne and wilbit reacted with hooray emoji
fuyfuy reacted with heart emoji
@rainersigwald I see this still has no milestone. Any plans to address at some point?
I had the same issue. When I modified a project and changed its assembly name, an NUnitTest project referencing the modified project couldn’t build anymore. Other projects referencing the modified project wasn’t affected.
I noticed that this error was purely because of a space in the middle of the new AssemblyName of the modified project. When I removed the space NUnit project started working again.
This bug is basically preventing me from having a space in name of any assembly which has a unit test.
workaround: rename assembly and remove spaces
i’m getting this error in visual studio 2019 using a solution with a mix of old-style and new style multi-targeted csproj files.
not sure where to go from here.
Not sure if this is related But I came here for the error, whil inspecting my csporj I noticed I had somehow included the same projectreference twice! After removing the duplicate my error went away. So at least there are more reasons that you can get this error
This is very problematic for CMake projects that use include_external_msproject() to add manually crafted multi-target C# projects. Workaround does not work in this case.
I had the same double project reference in the csproj as others, removing that fixed it.
SimonCropp
added a commit
to Fody/Fody
that referenced
this issue
Mar 27, 2021
tom-englert
added a commit
to tom-englert/SplashScreen.Fody
that referenced
this issue
May 31, 2021
@rokups — did you find a solution for the problem with include_external_msproject()? I seem to be stumbling over the same issue.
I do not remember. I am not dealing with this issue any more, but i can not find any relevant commits from the time of my post. Not sure if this happened in some experimental branch that i later scrapped… Sorry for being useless 
After long struggles with the problem using include_external_msproject() I finally found an applicable workaround on wixtoolset/issues#5705:
<Target Name="GetTargetPath" Returns="@(_FakeOutputPath)">
<ItemGroup>
<_FakeOutputPath Include="$(MSBuildProjectDirectory)$(PackageOutputPath)$(AssemblyName).dll" />
</ItemGroup>
</Target>
I seemed to get this after changing TargetFramework —> TargetFrameworks. The project I did this in started failing to build, but only in builds with other projects that depended on it (worked when I built it by itself). In the end I only needed one target framework so dropped the s again and that seemed to force VS to re-evaluate something that no amount of cleaning/rebuilding or opening/closing VS could solve. 🤷🏻♂️
I added a comment to your report @ghidalgo3. It’s too complicated to create a simple repro though.
NightOwl888
added a commit
to NightOwl888/ICU4N
that referenced
this issue
Mar 24, 2022
NightOwl888
added a commit
to NightOwl888/ICU4N
that referenced
this issue
Mar 24, 2022
I had the same issue. When I modified a project and changed its assembly name, an NUnitTest project referencing the modified project couldn’t build anymore. Other projects referencing the modified project wasn’t affected.
I noticed that this error was purely because of a space in the middle of the new
AssemblyNameof the modified project. When I removed the space NUnit project started working again.This bug is basically preventing me from having a space in name of any assembly which has a unit test.
workaround: rename assembly and remove spaces
This was the fix for me, using xUnit. My Test assembly was referencing several projects, and the problems were only with the ones that had spaces in them, but I never would have thought that this sort of thing would still cause problems in 2022.
For me this issue got introduced when I started setting TargetPlatformMinVersion in the UWP project, because I wanted a smaller min-version but wanted to use the newer SDK. Only happens to the project referencing the multi-targeted project (which have the same min/max versions for UWP).
Found a workaround for UWP case: In the second project pluralize TFM so it says TargetFrameworks and problem goes away 🤦
This issue might occur when building .NET projects via continuous integration in Azure DevOps as well as when building from Visual Studio after upgrading the version of Visual Studio. To fix the error you may need to rebuild the project or add the rebuild in MSBuild command (If you are using MSBuild)
The target “Build” does not exist in the project. (MSB4057)
The target “Package” does not exist in the project. (MSB4057)
There are multiple solutions for this issue as listed below, you can use any of the ones listed below
Solution 1: if it’s Project is not found ,then add a Rebuild to MSBuild as shown below
"msbuild.exe MySolution.sln /t:Project1:Rebuild;Project2:Rebuild;Project3:Rebuild /p:Configuration=Release /p:DebugType=None /p:OutputPath="C:UsersmyuserDesktopBuild""
Solution 2: Deleting the .vs folder has resolved this issue for the users who were using VS2017 or later
Solution 3: If you are facing this issue in Azure DevOps, use Visual Studio Build instead of MSBuild
Tags: MSB4057target Package
You may also like…
Background
I had been struggling with the error «MSB4057: The target Package does ont exist in project» and found many articles on how to fix it. However, unfortunately, none of them helped me. So, I took a step back and evaluated the projects closely. In our shop, we work with branching. The issue was that the same project in one branch worked (when MSDeploy was executed), another did not. When I compared the projects, I found this one entry (see below) was missing in the project file that was throwing the exception. When I would add it in the project (that was throwing the exception), MSDeploy worked, (for confirmation) when I removed it, it failed again.
Posting in hopes to help someone that does not have a working project.
$(MSBuildExtensionsPath32)MicrosoftVisualStudiov$(VisualStudioVersion)
Using the Code
Entering the following line within the project fixed the issue.
$(MSBuildExtensionsPath32)MicrosoftVisualStudiov$(VisualStudioVersion)
The full entry that you use to paste into your project file looks like the following. Please be aware that all configurations should be researched for your particular project. I added a few additional articles to review in order to understand the entry.
<Import Project="$(VSToolsPath)WebApplicationsMicrosoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
Points of Interest
The purpose for this entry is to help project compatibility when opening a project in later versions of Visual Studio.
Other articles to better understand the entry:
- https://blogs.msdn.microsoft.com/webdev/2012/08/21/visual-studio-project-compatibility-and-visualstudioversion/
- http://sedodream.com/PermaLink,guid,a5894bad-f2a1-441a-a5b2-74f16c6cf8aa.aspx
This member has not yet provided a Biography. Assume it’s interesting and varied, and probably something to do with programming.
We recently ran into a blocking issue when deploying a custom .net core Azure WebJob:
Error MSB4057: The target «MSDeployPublish» does not exist in the project.
The project would build successfully, but the deployment would fail.
- I made sure that the solution was running as Administrator.
- I made sure that Microsoft.Web.WebJobs.Publish.1.1.0 NuGet package was installed and applied correctly.
- I even removed and re-applied the NuGet package.
But the solution would not deploy.
Solution:
I found Rhizohm’s blog post which recommends a manual edit to your webjob’s CSPROJ file to resolve the issue. it appears that this issue has been around since at least Visual Studio 2015.
I resolved my publish issue by manually adding the following to the bottom of your webjob’s CSPROJ file:
<Import Project="$(MSBuildToolsPath)Microsoft.CSharp.targets" /> <Import Project="..packagesMicrosoft.Web.WebJobs.Publish.1.1.0toolswebjobs.targets" Condition="Exists('..packagesMicrosoft.Web.WebJobs.Publish.1.1.0toolswebjobs.targets')" />
Thanks Rhizohm!
Upon Further Review
Earlier this month, we upgraded our solutions from .net core 1.1 to .net core 2.0, and ran into this annoying bug with machine.config & System.Tuple reference. We ran into an reference error for System.Tuple when we tried to run EF database-update commands, but the solution could not build/publish with it in. We weren’ crazy about the idea of manually editing the machine.config during EF updates & build/deployments — so we decided to rebuild our solution as a brand new .net core 2.0 solution (not our existing one that was upgraded from .net core 1.0 beta, 1.0 RTM and 1.1 RTM). That resolved the strange System.Tuple error…. BUT that is when we lost the Import Project node for Microsoft.Web.WebJobs.Publish in our webjob’s project file.