VS2010 Build of .NET v3.5 projects fail due to a potential .NET v4.0 reference - visual-studio-2010

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.

Related

Publish a Windows Application Package Project via command line

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.

Error while running MSBuild.SonarQube.Runner against C# project

I’m trying to use MSBuild SonarQube scanner for my C# project. RootFolder has a .sln file, and each project (.csproj) is created in a separate folder inside the root folder. I've the project property file in RootFolder.
SonarQube server (LTS version 6.7.5) is up fine.
My Current env details:
Visual Studio 2010
.Net Framework 4.5.2
MSBuild version 4
sonarScanner for MSBuild 4.3.1.1372
Sonar Csharp Plugin version : 7.3.2.6129
When I’m trying to run below ‘begin’ command from project root directory, I see this error:
M:\myProjectCsharp>MSBuild.SonarQube.Runner.exe begin /k:”myProjectCsharp”/n: “myProjectCsharp”/v:”1.0”
Unhandled Exception: System.MissingMethodException: Method not found: '!!0[] System.Array.Empty()'.
at SonarScanner.MSBuild.Program.Execute(String[] args, Boolean showDeprecatedWarning)
at MSBuild.SonarQube.Runner.Program.Main(String[] args)
I guess it has something to do with compatibility of .Net Framework or MSBuild version ?
Also, what's the role of visual studio here, I already got.sln, .csproject and their corresponding .cs files in respective project directory under RootFolder 'myProjectCsharp'
(I don’t see any error if I simply run the sonar-scanner-msbuild-4.3.1.1372-net46\sonar-scanner-3.2.0.1227\bin\sonar-scanner but this doesn’t seems to update anything on dashboard (Just show 0 Bugs,Vulnerabilities & code smells) )
Any clue please ?
Thanks.

VS2017 MSB4057 The target "CreateManifestResourceNames" does not exist in the project

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

MsBuild error MSB1025 - System.Threading.Tasks.Dataflow not found (following fake generation problems)

I have a problem with the standard MSBuild.exe used on our Team Build server, the standard version used is in
"C:\Windows\Microsoft.NET\Framework\v4.0.30319", version 4.0.30319.18408 or
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319" respectively (same version).
Using this version leads to Fake dlls not being generated in the same way as on our local development machines (i.e. some fake methods are missing on the server), resulting in broken builds (unit tests) on the TFS.
I updated the build definition template to use the MSBuild version located under "C:\Program Files (x86)\MSBuild\12.0\Bin" as it is more recent (version 12.0.30723.0), however, this results in an error MSB1025, System.Threading.Tasks.Dataflow, Version=4.5.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a not found.
Update
Further investigation - manually adding the System.Threading.Tasks.Dataflow.dll with the correct version number to the MSBuild directory results in a broken build with
Unsupported ToolsVersion 12.0
Manually setting the ToolVersion in the Microsoft.TeamFoundation.Build.Workflow.Acitvities.MSBuild element to "4.0" results in a broken build with
Cannot set unknown member "Microsoft.TeamFoundation.Build.Workflow.Activities.MSBuild.ToolVersion"
So... no real improvement.
Any ideas how to fix this?
Fakes is sensitive to the Visual Studio version. Try passing /p:VisualStudioVersion=12.0 to MSBuild arguments. Also avoid handling System.* assemblies manually.

Can't see deployed Biztalk Project Assemblies in GAC?

I have a Biztalk project that has the following settings:
General > Redeploy > True
Local Machine > Install to Global Assembly Cache > True
All projects involved have an SNK file generated. However, I removed a reference and it hasn't been cleaned out of the GAC according to biztalk documentation. When I attempt to locate my installed assembly in c:\windows\assembly, I cannot find my BiztalkProject.DLL or the BiztalkLibraries.DLL project there. Is it possible this is a permissions issue, or am I dealing with a different issue?
C:\Windows\Assembly is the CLR 2.0 GAC (.Net 2.0 through 3.5).
If you are using BizTalk Server 2010 or later, you will find the GAC'd Assemblies in the CLR 4.0 GAC at C:\Windows\Microsoft.NET\assembly\GAC_MSIL
You can also use gacutil.exe. Open the Developer Command Prompt, and type
gacutil /l | find "AssemblyName"
to check if it's in the GAC and
gacutil /u AssemblyName
to remove it. Note that AssemblyName can just be the first part of the Fully Qualified Name.

Resources