So I'm trying to automate the builds for a Xamarin project and integrate it to our company's CI pipeline. I'm not really familiar with .NET/Xamarin building process, but I've done it before following the really short guide for CI they have.
I'm using a standalone macOS build server (since we have to build iOS .ipa with XCode) with Visual Studio for this purpose.
Turns out, this time, we have a local dependency (some library we needed to slightly modify) integrated as a git-submodule on the project. The developers are all using the IDE for this and it loads/unloads and resolves all the dependencies without problem (or at least they told me that): they just have to hit the "play" button and it simply builds everything.
I'm trying to find a way to the same programmatically (using msbuild on the CI server) and here's where the problems start: so far, every time I run
$ nuget restore projectApp.sln
[...] # first get the project packages
$ msbuild \
/p:Configuration="Debug" \
/p:Platform="iPhone" \
/p:BuildIpa=true \
/p:IpaPackageDir="./Builds" \
/t:Build project.sln
... I get ~250 "are you missing an assembly reference?" errors. I assumed that meant the library dependencies were not found, so I tried resolving them with nuget:
$ nuget restore TK.CustomMap/TK.CustomMap.sln
[...]
But running msbuild again returns the exact same output:
[...]
Project "/Users/builder/project/projectApp.sln" (1) is building "/Users/builder/project/projectApp/projectApp.csproj" (2) on node 1 (default targets).
Project "/Users/builder/project/projectApp/projectApp.csproj" (2) is building "/Users/builder/project/TK.CustomMap/TK.CustomMap/TK.CustomMap/TK.CustomMap.csproj" (3:2) on node 1 (default targets).
CoreCompile:
[...]
"/Users/builder/project/projectApp.sln" (Build target) (1) ->
"/Users/builder/project/projectApp/projectApp.csproj" (default target) (2) ->
"/Users/builder/project/TK.CustomMap/TK.CustomMap/TK.CustomMap/TK.CustomMap.csproj" (default target) (3:2) ->
(CoreCompile target) ->
Api/Google/GmsDirection/GmsDirection.cs(2,18): error CS0234: The type or namespace name 'Http' does not exist in the namespace 'System.Net' (are you missing an assembly reference?) [/Users/builder/project/TK.CustomMap/TK.CustomMap/TK.CustomMap/TK.CustomMap.csproj]
Api/Google/GmsDirection/GmsDirection.cs(5,7): error CS0246: The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?) [/Users/builder/project/TK.CustomMap/TK.CustomMap/TK.CustomMap/TK.CustomMap.csproj]
First of all, I want to know if there's a way to build the library fork on a different, internal pipeline and serve it + handle it in the project using nuget (like I'd do with the original version).
And then, in case that is too much over-engineering, how to properly build locally the whole project (including the library) and link it all together.
Related
How can I publish the UWP package via command line?
I have a WPF application that is packaged with a Windows Application Package Project that ends up being published to the Microsoft Store.
In order to be accepted in the Store, the WPF project needs to be compiled with a preprocessor directive (that I named as "UWP"), deactivating stuff that are not allowed for Store apps.
I'm in the process of migrating the WPF app from .NET Framework 4.8 to .NET 5 and along with that I'm trying to streamline my publishing process via command line.
Is there any way to configure or update the package to support ARM64?
The app will be published outside the Store as x86, x64 and ARM64 and I intend to do the same for the Store version.
When checking the WAPP, I noticed that ARM64 is not available on the list. As you can see in the screenshot, I was able to create a ARM64 build profile, but the architecture is not available on the table.
What have I tried? (Command line issue)
I tried running this command:
MSBuild.exe C:\Project-UWP\Project.UWP\Project.UWP.wapproj /p:DefineConstants=UWP /p:Configuration=Release;AppxBundle=Always;AppxBundlePlatforms="x86|x64|ARM64" /p:OutDir="..\Publish\UWP"
But got these errors:
Microsoft (R) Build Engine version 16.11.0+0538acc04 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 29/09/2021 22:09:19.
Project "C:\Project-UWP\Project.UWP\Project.UWP.wapproj" on node 1 (default targets).
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1718,5): warning NU1702: ProjectReference 'C:\Project\Project.csproj' was resolved using '.NETCoreApp,Version=v6.0' instead of the project target framework '.NETFramework,Version=v4.5.1'. This project may not be fully compatible with your project. [C:\Project-UWP\Project.UWP\Project.UWP.wapproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1718,5): warning NU1702: ProjectReference 'C:\Project\Project.csproj' was resolved using '.NETCoreApp,Version=v6.0' instead of the project target framework '.NETFramework,Version=v4.5.1'. This project may not be fully compatible with your project. [C:\Project-UWP\Project.UWP\Project.UWP.wapproj]
_ResolveVCLibDependencies:
Searching for SDKs targeting "UAP, 10.0.20348.0".
Project "C:\Project-UWP\Project.UWP\Project.UWP.wapproj" (1) is building "C:\Project\Project.csproj" (2:9) on node 1 (publish target(s)).
C:\Program Files\dotnet\sdk\5.0.401\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1047: Assets file 'C:\Project\Project\obj\project.assets.json' doesn't have a target for 'net5.0-windows/win-x86'. Ensure that restore has run and that you have included 'net5.0-windows' in the TargetFrameworks for your project. You may also need to include 'win-x86' in your project's RuntimeIdentifiers. [C:\Project\Project.csproj]
Done Building Project "C:\Project\Project.csproj" (publish target(s)) -- FAILED.
Done Building Project "C:\Project-UWP\Project.UWP\Project.UWP.wapproj" (default targets) -- FAILED.
Build FAILED.
"C:\Project-UWP\Project.UWP\Project.UWP.wapproj" (default target) (1) ->
(_GetProjectReferenceTargetFrameworkProperties target) ->
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1718,5): warning NU1702: ProjectReference 'C:\Project\Project.csproj' was resolved using '.NETCoreApp,Version=v6.0' instead of the project target framework '.NETFramework,Version=v4.5.1'. This project may not be fully compatible with your project. [C:\Project-UWP\Project.UWP\Project.UWP.wapproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1718,5): warning NU1702: ProjectReference 'C:\Project\Project.csproj' was resolved using '.NETCoreApp,Version=v6.0' instead of the project target framework '.NETFramework,Version=v4.5.1'. This project may not be fully compatible with your project. [C:\Project-UWP\Project.UWP\Project.UWP.wapproj]
"C:\Project-UWP\Project.UWP\Project.UWP.wapproj" (default target) (1) ->
"C:\Project\Project.csproj" (publish target) (2:9) ->
(ResolvePackageAssets target) ->
C:\Program Files\dotnet\sdk\5.0.401\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1047: Assets file 'C:\Project\obj\project.assets.json' doesn't have a target for 'net5.0-windows/win-x86'. Ensure that restore has run and that you have included 'net5.0-windows' in the TargetFrameworks for your project. You may also need to include 'win-x86' in your project's RuntimeIdentifiers. [C:\Project\Project.csproj]
2 Warning(s)
1 Error(s)
Time Elapsed 00:00:01.31
Notice that there are warnings related to framework references:
ProjectReference C:\Project\Project.csproj was resolved using .NETCoreApp,Version=v6.0 instead of the project target framework .NETFramework,Version=v4.5.1.
This project may not be fully compatible with your project. Microsoft.Common.CurrentVersion.targets 1719
The WPF project was set to use .NET 5, so I don't see why there's any reference to .NETCoreApp 6 or .NET Framework 4.5.1.
What have I tried? (Missing ARM64 issue)
I created a WAPP from scratch and saw that the option for ARM64 appeared in the architecture table.
But when publishing manually via the context menu, I'll get this error:
The specified RuntimeIdentifier 'win-ARM64' is not recognized.
I've just updated my VS to ver. 16.8.3 and now suddenly I am getting this error:
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1720,5): error :
Internal MSBuild error: Non-CrossTargeting GetTargetFrameworks target should not be used in cross targeting (outer) build
Not sure at all what to do about this.
We have been working on this project for years and never had such an issue.
Any thoughts?
Seems that the problem is with projects that use multiple .net frameworks AND they referenence ANOTHER project that uses multiple .net frameworks
I have a MINIMAL sample solution at: my public drive
The solution contains two minimal/empty projects that are technically the same except that the one named Microdesk.DbApp referencing the one name Microdesk.Infrastructure.
The Infrastructure project compiles fine while the DbApp project throws the above error.
This solution was working fine for us for multiple years and broke with the latest VS release 16.8.3
Okay, partially my bad.
I did re-compile the EMPTY sample project and found that despite the compiler error, the solution does build.
1>------ Rebuild All started: Project: Microdesk.BIMrxCommon.Infrastructure, Configuration: Debug2020 Any CPU ------
1> Microdesk.BIMrxCommon.Infrastructure -> C:\Work\Microdesk.BIMrx\bin\Debug2020\Microdesk.BIMrxCommon.Infrastructure.dll
2>------ Rebuild All started: Project: Microdesk.BIMrxCommon.DbApp, Configuration: Debug2020 Any CPU ------
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1720,5): error : Internal MSBuild error: Non-CrossTargeting GetTargetFrameworks target should not be used in cross targeting (outer) build
2> Microdesk.BIMrxCommon.DbApp -> C:\Work\Microdesk.BIMrx\bin\Debug2020\Microdesk.BIMrxCommon.DbApp.dll
========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========
BUT if you try to USE anything from the Infrastructure project in the referencing DbApp project then the Solution will NOT compile
Rebuild started...
1>------ Rebuild All started: Project: Microdesk.BIMrxCommon.Infrastructure, Configuration: Debug2020 Any CPU ------
2>------ Rebuild All started: Project: Microdesk.BIMrxCommon.DbApp, Configuration: Debug2020 Any CPU ------
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1720,5): error : Internal MSBuild error: Non-CrossTargeting GetTargetFrameworks target should not be used in cross targeting (outer) build
2>C:\Work\Microdesk.BIMrx\BIMrxCommon\Microdesk.BIMrxCommon.DbApp\DerivedClass.cs(1,29,1,4
): error CS0234: The type or namespace name 'Infrastructure' does not exist in the namespace 'Microdesk.BIMrxCommon' (are you missing an assembly reference?)
2>C:\Work\Microdesk.BIMrx\BIMrxCommon\Microdesk.BIMrxCommon.DbApp\DerivedClass.cs(5,33,5,42): error CS0246: The type or namespace name 'BaseClass' could not be found (are you missing a using directive or an assembly reference?)
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========
I did upload a second sample project named "Microdesk.BIMrx (2).zip" to the previous OneDrive directory
When I test your issue in your side, I did not face the same behaviors as you described. So I guess that there is some issues on your current vs environment due to the update. And maybe the update broke some tools of VS.
So please try the following steps to troubleshoot it:
Suggestions
1) disable any third party installed extensions under Extensions-->Manage Extensions-->Installed
2) close VS, delete .vs hidden folder, every bin and obj folder of your project.
and also delete all cache files under C:\Users\xxx(current user)\AppData\Local\Microsoft\VisualStudio\16.0_xxx\ComponentModelCache
Then, restart VS to test again.
3) or create a new project and then migrate the content from the old into the new one to test whether the issue is related to your VS or the special project itself.
4) If this does not work, do an initialization operation on your VS.
Close VS, delete the whole user folder under C:\Users\xxx(current user)\AppData\Local\Microsoft\VisualStudio\16.0_xxx and then restart VS to test again.
5) repair vs from the vs_installer
When VS2017 was used to create a stateful solution, producing the standard boilerplate code, the resulting two projects have two different MSBuild versions.
The application uses MSBuild version 1.5.0.
The service uses MSBuild version 1.6.0 (the current "latest").
If I run the solution this way, it runs fine on my local Service Fabric cluster.
But when after I use NuGet to update the application's MSBuild to 1.6.0 (so both application and server projects use the same), the following errors occur.
Severity Code Description Project File Line Suppression State
Error The OutputPath property is not set for project 'gt_strd5.sfproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' P follow a project-to-project reference to this project, this project has belatform='x64'. This error may also appear if some other project is trying toen unloaded or is not included in the solution, and the referencing project does not build using the same or an equivalent Configuration or Platform. gt_strd5 C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 737
Severity Code Description Project File Line Suppression State
Error MSB4057 The target "CreateManifestResourceNames" does not exist in the project. gt_strd5 C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 2630
I found that after the change, some references in the application's project file continued to reference MSBuild 1.5.0. In my case, the gt_strd5.sfproj file contained four references which needed to be updated from 1.5.0 to 1.6.0. See the snippets from the XML below.
Import Project="..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.props" Condition="Exists('..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.props')"
.....
Import Project="..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets" Condition="Exists('..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets')"
To verify this, I went back a couple times and was able to reproduce both the issue and this solution.
Hope it saves someone else some time.
Best Regards
I was getting this error into PCF control.
Run Developer Command Prompt VS2017/ VS2019
a) Remove white space from your folder like Test%20-%20PCFs (source control generated name) should be TestPCFs
b) Go to pcf project folder from cmd line & run msbuild /t:restore
b) Go to cds project folder from cmd line & run msbuild /t:restore
c) On cds project folder, run msbuild
d) For release deployment run msbuild /p:configuration=Release
For other types of projects
a) Remove white space from your folder name
b) run msbuild /t:restore
c) run msbuild
I'm pushing a NancyFx solution to AppHarbor, but it fails to build since AppHarbor isn't restoring the packages.
Package restore is defined in my solution file though.
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = ".nuget", ".nuget", "{313EB245-8733-45FC-82B3-6C1404446A50}"
ProjectSection(SolutionItems) = preProject
.nuget\NuGet.Config = .nuget\NuGet.Config
.nuget\NuGet.exe = .nuget\NuGet.exe
.nuget\NuGet.targets = .nuget\NuGet.targets
EndProjectSection
EndProject
Here is a relevant piece of the AppHarbor log.
Build started 11/21/2012 8:50:07 AM.
1>Project "D:\temp\cqcytykz.jkt\input\src\xxx\xxx.sln" on node 1 (default targets).
1>ValidateSolutionConfiguration:
Building solution configuration "Release|Mixed Platforms".
1>Project "D:\temp\cqcytykz.jkt\input\src\xxx\xxx.sln" (1) is building "D:\temp\cqcytykz.jkt\input\src\xxx\xxx\xxx.csproj" (2) on node 1 (default targets).
2>PrepareForBuild:
Creating directory "obj\Release\".
ResolveAssemblyReferences:
Primary reference "Nancy".
2>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1578,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Nancy". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [D:\temp\cqcytykz.jkt\input\src\xxx\xxx\xxx.csproj]
Anyone having an idea what's missing?
Is there a section in the csproj that references the NuGet.targets file? What you have just shows the items in the solution, the project needs a reference to the targets file to actually know what to execute upon build of a project.
The NuGet support isn't really anything special that MSBuild/VS knows about it (though VS does have an extension to make some things easier). The stuff (which should be inserted if you use the VS extensions "Enable Package Restore" functionality) is what tells MSBuild it needs to run an external command during build, which is what then restores the packages :-)
Attempting to build a Visual Studio 2010 solution with 132 projects which do not use any file references (only project references). When I build the entire solution, I get many build errors like this:
The type or namespace name 'xxxx' does not exist in the namespace '<namespace name>' (are you missing an assembly reference?)
The target framework version for ALL projects in the solution is v3.5.
Hence I started building projects one by one based on the Project Build Order. And on one of the projects (say project A), I get the below info in the Build Output (note the framework version). This project A builds successfully.
When I build the next project, say project B, which references project A through a project reference (not file reference), then it throws the above build error. Hence it seems project B is the culprit.
Compile complete -- 0 errors, 54 warnings
<ProjectName> -> <filepath>\<filename>.dll
Microsoft (R) .NET Global Assembly Cache Utility. Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Details of project B
Solution configuration is Debug.
In the References tree of project B, the properties of the project A reference shows
1) "Runtime Version" as v2.0.50727.
2) "Copy local" as True.
3) "Strong Name" as True.
4) "Version" as 1.0.xxxx.xx (as specified in the AssemblyInfo.cs of project A)
5) There is no "Specific Version" key (because it is a project reference)
the AssemblyInfo.cs of project B has the following:
1) [assembly: ComVisible(false)]
2) [assembly:Guid("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx")]
3) [assembly:AssemblyVersion("1.0.xxxx.xx")]
4) [assembly:AssemblyFileVersion("9.0.xxxx.xx")]
the project B properties has the following:
1) "Target Framework" as ".NET Framework 3.5"
2) "Output Type" as "Class Library"
3) "Treat warnings as errors" as "None"
My Question(s)
Now, the target framework specified in the properties of ALL my projects is .NET Framework 3.5.
How does the build engine use a GAC Utility of v4.0 when my target framework is v3.5?
Searched all files to see if .NET 4.0 is configured somewhere but could not find it.
This seems to be potentially the root cause of the above issue. Or am I missing something else? I believe I have covered the usual suspects.
Also why does the Runtime Version of project A reference in project B say v2.0.50727 when the target framework version for both projects is v3.5?
PS:
I tried removing the project reference and adding its file reference instead, still gives the same build error. (This usually used to work before when it was a long name issue but its not in this case).
UPDATE 1:
The build output for the above build error is:
Compile complete -- 13 errors, 0 warnings
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9):
warning MSB3258: The primary reference "<project A reference name>" could not be resolved
because it has an indirect dependency on the .NET Framework assembly
"mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=xxxxxxxxxxx"
which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.
UPDATE 2:
The Post-build event command-line for project A has the following which explains why the build uses the GAC Utility of v4.0! Now I need to figure how to get the v3.5 Gacutil in there.
My second question still stands though.
cd "$(ProjectDir)"
cd ..\..\..\Bin
gacutil.exe /if "$(TargetPath)"
To answer your second question:
.Net 3.0 and .Net 3.5 are simply new DLLs that run on the existing CLR 2.0.
There are no runtime versions between 2.0 and 4.0.