Switched targeted .NET versions and now project won't build - c#

I'm running VS 2010 and I have a project which was originally set to build to .NET 4.0. This rev of .NET is too high for many of the windows platforms this app is expected to run and so I switched it from .NET 4.0 to .NET 2.0. Now, the project doesn't build.
At first I was getting null reference exceptions with the project resources. I found this link on MSDN forums which proved helpful in fixing that issue. Essentially, the answer (among the many) that worked was to change all instances of:
Version=4.0.0.0
to
Version=2.0.0.0
... in the *.resx files. I did this to all *.resx files I could find in the project directory. Walla, no more null reference exceptions during the build. However, now the project simply fails to build and the build window offers nothing in way of help to resolve. This is literally what's there:
2>CoreCompile:
2> C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig /nowarn:1701,1702 /nostdlib+ /platform:x86 /errorreport:prompt /warn:4 /define:TRACE /reference:C:\Users\afalanga\Dev\Tools\Program\FrontEnd\Resources\WrapNativeLibrary.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Deployment.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Management.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /debug:pdbonly /filealign:512 /optimize+ /out:obj\x86\Release\FrontEnd.exe /resource:obj\x86\Release\FrontEnd.Panel.resources /resource:obj\x86\Release\FrontEnd.PrivilegesForm.resources /resource:obj\x86\Release\FrontEnd.Main.resources /resource:obj\x86\Release\FrontEnd.Properties.Resources.resources /resource:obj\x86\Release\FrontEnd.SoftwareLicense.resources /resource:Resources\WrapNativeLibrary.dll,WindowsUpdateTool.Resources.WrapNativeLibrary.dll /resource:Resources\INativeLibrary.dll,FrontEnd.Resources.INativeLibrary.dll /target:exe /win32icon:Resources\FrontEnd.ico /win32manifest:Resources\app.manifest Environment.cs Check.cs Exceptions.cs Updater.cs LibAccess.cs PrivilegesForm.cs Form1.Designer.cs OSInfo.cs Constants.cs PersonalizationManager.cs Silent.cs drivePanel.cs drivePanel.Designer.cs Main.cs Main.Designer.cs Program.cs Properties\AssemblyInfo.cs SoftwareLicense.cs SoftwareLicense.designer.cs VerticalProgressBar.cs Properties\Resources.Designer.cs Properties\Settings.Designer.cs
2>
2>Build FAILED.
Is it due to the fact that the C# compiler being referenced is the 4.0 version? At this point, I'm completely at a loss for what to check. I'm considering a fresh checkout of the branch for this code from TFS and trying there but haven't gone that route yet. I would appreciate any insight as everything I can see from the project properties says it should be targeting .NET 2.0 and it "should" build.
Thanks,
Andy

When you're downgrading your build target, you might be better off to start with a new project, change the build target then import your code into it. This way all your core dependencies start out right, and you'll only have to worry about the code being able to work.

Related

Building cmake generated UWP windows desktop project results in error MC6000 (missing WindowsBase, ...)

I created a simple Windows UWP solution with windows visual studio 2019.
I did not make any changes to it but closed visual studio.
Then I wrote a simple cmake file for it.
However, it fails in "cmake --build" like this:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(268,9):
error MC6000: Project file must include the .NET Framework assembly
'WindowsBase, PresentationCore, PresentationFramework' in the reference list.
[App1\out\App1.csproj]
When I add the requested .NET files with VS_DOTNET_REFERENCES property, there is a different error:
App1\MainPage.xaml(9,5): error MC3074: The tag 'ThemeResource' does not exist
in XML namespace 'http://schemas.microsoft.com/winfx/2006/xaml/presentation'.
Line 9 Position 5. [App1\out\App1.csproj]
I also tried adding all and combinations of these calls to CMakeLists.txt but they did not have any effect:
set_property (SOURCE "App.xaml" PROPERTY VS_XAML_TYPE "ApplicationDefinition")
target_compile_options (App1 PRIVATE "/langversion:default")
set_property (TARGET App1 PROPERTY DOTNET_TARGET_FRAMEWORK_VERSION "v4.7.2")
set_property (TARGET App1 PROPERTY WIN32_EXECUTABLE TRUE)
I cannot overcome these problems.
I generate and compile the solution like this:
cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=10.0 -S . -B out
cmake --build out
Cmake version is 3.14.19050301-MSVC_2.
The source files are here, including the original by visual studio created solution files and my written CMakeLIsts.txt file.
Expected result would be a cmake compiling solution which looks as much as possible like the native solution.
Probably there is just a simple error but I cannot find it.

MSBuild fails for solution with project dependencies

The build for my solution, which contains multiple projects, suddenly appears to be broken and the cause of the issue isn't clear. All of the projects in the solution target the same framework (4.5.1), however, some of the projects' dependencies might be targeting an earlier version of the framework. As of last week, we were able to successfully build solutions that fall under this scenario. Starting last Thursday, the builds appear to be broken without any changes to the build server or the solution.
To illustrate and remove some of the complexities with our production setup, I created a sample solution which mimics the behavior.
Project structure:
CBI Solution
CBI website
CBI Implementation Library
CBI Core library, defining the interfaces
Target Framework Version for the website and class libraries is 4.5.1
Replication Steps
Solution 1
Github repo: https://github.com/NikitaGolovko/Solution1.git
Build, using MSBuild 14. My command is:
msbuild.exe "%SOLUTION1PATH%\CBILite.sln" /p:platform="Any CPU" /p:configuration="Release" /v:d
Output
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /localhost_61806 -p cbi\ -u -f PrecompiledWeb\lo
calhost_61806\
Microsoft (R) ASP.NET Compilation Tool version 4.7.2046.0
Utility to precompile an ASP.NET application
Copyright (C) Microsoft Corporation. All rights reserved.
Done executing task "AspNetCompiler".
Task "Message" skipped, due to false condition; (!((false) or ('$(AspNetConfiguration)' == 'Debug') or ('$(AspNetConfig
uration)' == 'Release'))) was evaluated as (!((false) or ('Release' == 'Debug') or ('Release' == 'Release'))).
Done building target "Build" in project "cbi.metaproj".
Done Building Project "D:\Work\DotNet\Nikita\Solution1\cbi.metaproj" (default targets).
Done executing task "MSBuild".
Done building target "Build" in project "CBILite.sln".
Done Building Project "D:\Work\DotNet\Nikita\Solution1\CBILite.sln" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:03.10
Full output is located here: https://github.com/NikitaGolovko/Solution1/blob/master/MSBuild_Output.txt
Solution 2
Github Repo: https://github.com/NikitaGolovko/Solution2.git
The solution is nearly identical to the Solution1, with the only exception being a dependency for Unity in CBI Implementation library. To simplify the process and eliminate the nuget restore step, I have included nuget packages with the solution.
Build, using MSBuild 14. My command is:
msbuild.exe "%SOLUTION2PATH%\CBILite.sln" /p:platform="Any CPU" /p:configuration="Release" /v:d
Output
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /localhost_61806 -p cbi\ -u -f PrecompiledWeb\lo
calhost_61806\
Microsoft (R) ASP.NET Compilation Tool version 4.7.2046.0
Utility to precompile an ASP.NET application
Copyright (C) Microsoft Corporation. All rights reserved.
D:\Work\DotNet\Nikita\Solution2\cbi\Index.aspx.vb(5): error BC30002: Type 'CBILite.Calculator' is not defined. [D:\Work
\DotNet\Nikita\Solution2\cbi.metaproj]
The command exited with code 1.
Done executing task "AspNetCompiler" -- FAILED.
Done building target "Build" in project "cbi.metaproj" -- FAILED.
Done Building Project "D:\Work\DotNet\Nikita\Solution2\cbi.metaproj" (default targets) -- FAILED.
Done executing task "MSBuild" -- FAILED.
Done building target "Build" in project "CBILite.sln" -- FAILED.
Done Building Project "D:\Work\DotNet\Nikita\Solution2\CBILite.sln" (default targets) -- FAILED.
Build FAILED.
Full output is located here: https://github.com/NikitaGolovko/Solution2/blob/master/MSBuild_Output.txt
Observations
Bin folder
When looking in the bin folder of the website, I notice that CBILite.dll is missing after the build for Solution2, but present in Solution1.
TargetFrameworkVersion
Passing TargetFrameworkVersion in the MSBuild arguments does not appear to influence the build. I have attempted to pass 4.5, 4.5.1 to no avail. HOWEVER passing 3.5 results in the successful build. This is extremely strange.
Metaproj
When comparing Metaproj files generated for both solutions, the only observable and seemingly important difference is the lack of the TargetFrameworkVersion element. Solution1 (without dependencies), contains v.4.0 element. Solution2 (with the dependency) does not.
I didn't include metaproj files in the repo but can share them if needed.
Visual Studio
Building the solution in Visual Studio works just fine.
Additional thoughts
The issue manifested itself rather suddenly and seems to be affecting most of our solutions that have mixed projects (C#/VB + website). Web Projects continue to function normally.
I've attempted to use MSBuild 15, but it resulted in the same behavior.
There are a few workarounds
Retaining the metaproj file with the solution and modifying it manually by adding v4.5.1 element.
Adding an additional build step to manually copy CBILib.dll into the website project (via the batch file or other means).
Adding a refresh file for the website pointing to CBILib/bin/Release folder
While all of these solutions might work, they're certainly hacks and will present problems in the future.
I'm hoping someone else has a better suggestion on how to handle this.
Make sure you have installed the following NuGet packages:
Microsoft.NET.Test.Sdk
MSTest.TestAdapter
MSTest.TestFramework
Microsoft.NETCore.App (if you use .NET Core)

c# error CS1056: Unexpected character '$' with Jenkins or MSbuild

I have a requirement to work with Jenkins for Continues integration, in my code I have written code like
throw new ArgumentNullException($"The {nameof(Id)} cannot be null");
If I build the application it is building successfully but if I build this same application using MsBuild(or) Jenkins,
I am getting error like
Web\WebSharedHelper.cs "C:\WINDOWS\TEMP\.NETFramework,Version=v4.5.2.AssemblyAttributes.cs"
Security\ApiUserToken.cs(46,32): error CS1056: Unexpected character '$' [C:\Program Files (x86)\Jenkins\workspace\OssiaCICD\common\trunk\Cota.Common.Core\Cota.Common.Core.csproj]
Security\ApiUserToken.cs(58,32): error CS1056: Unexpected character '$' [C:\Program Files (x86)\Jenkins\workspace\OssiaCICD\common\trunk\Cota.Common.Core\Cota.Common.Core.csproj]
Security\ApiUserToken.cs(62,26): error CS1056: Unexpected character '$' [C:\Program Files (x86)\Jenkins\workspace\OssiaCICD\common\trunk\Cota.Common.Core\Cota.Common.Core.csproj]
Done Building Project "C:\Program Files (x86)\Jenkins\workspace\OssiaCICD\common\trunk\Cota.Common.Core\Cota.Common.Core.csproj" (default targets) -- FAILED.
I am using v4.0.30319 FrameWork for MSBuild.
I fixed the problem by using C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe instead of C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe on jenkins.
The $ string interpolation symbol is only available in C# 6+. Make sure that you are compiling with C#6. C#6 is supported in MSBuild 14.0+.
If your Visual Studio version is older than 2015 then by default the IDE does not provide C#6 which you need to compile it.
Use Visual Studio 2015 or newer. It should resolve problem.
This problem can be resolved in a couple of ways. Please check my answer here
for the first option:
1st https://stackoverflow.com/a/42931980/819153
2nd option - Try to install the visual studio on the tfs where you run the continuous integration, that will save you a lot of headaches
As suggested by a gentleman here, I used C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe instead of C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe over the build agent.
And it helped me.
I have MSBuild Version 14.0.25420.1 in the build agent.
In my case, worked below..
Removed langversion nodes and added netstandard reference to csproj for msbuild to work with Jenkins or msbuild command.
commented below lines in .csproj file.
<!-- <LangVersion>8.0</LangVersion>-->
And added <Reference Include="netstandard" /> for more-info

MonoMac Build Error From Default Template

I am trying to use MonoDevelop 3.0.3.2 to create a MonoMac application. I created a new MonoMac solution and tried running the template created after creating the solution, but this is my build output:
Building Solution: MAC1 (Debug|x86)
Building: MAC1 (Debug|x86)
Performing main compilation...
/Library/Frameworks/Mono.framework/Versions/2.10.9/bin/dmcs /noconfig
"/out:/Users/zgillis/Projects/MAC1/bin/Debug/MAC1.exe"
"/r:/Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/4.0/System.dll"
"/r:/Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/4.0/System.Xml.dll"
"/r:/Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/4.0/System.Core.dll"
"/r:/Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/4.0/System.Xml.Linq.dll"
"/r:/Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/4.0/System.Drawing.dll"
"/r:/Applications/MonoDevelop.app/Contents/MacOS/lib/monodevelop/AddIns/MonoDevelop.MonoMac/MonoMac.dll" /nologo /warn:4 /debug:full /optimize- /codepage:utf8 /platform:x86
"/define:DEBUG" /t:exe "/Users/zgillis/Projects/MAC1/MainWindow.cs"
"/Users/zgillis/Projects/MAC1/MainWindowController.cs"
"/Users/zgillis/Projects/MAC1/MainWindow.designer.cs"
"/Users/zgillis/Projects/MAC1/Main.cs" "/Users/zgillis/Projects/MAC1/AppDelegate.cs"
"/Users/zgillis/Projects/MAC1/AppDelegate.designer.cs"
Copying content files
Copying '/Users/zgillis/Projects/MAC1/bin/Debug/MAC1.exe' to
'/Users/zgillis/Projects/MAC1/bin/Debug/MAC1.app/Contents/MonoBundle/MAC1.exe'
Copying '/Users/zgillis/Projects/MAC1/bin/Debug/MAC1.exe.mdb' to
'/Users/zgillis/Projects/MAC1/bin/Debug/MAC1.app/Contents/MonoBundle/MAC1.exe.mdb'
Build complete -- 0 errors, 0 warnings
Updating application manifest
---------------------- Done ----------------------
Build successful.
Build failed. The given key was not present in the dictionary.
I am running Mac OS X Snow Leopard (10.6.8), and my Xcode version is 3.2.2.
It will not allow me to compile even the default MonoMac template, so I know I must have something configured incorrectly. I appreciate the help.
It looks like your version of Xcode is old - it's likely that MonoDevelop's support for reading values from the older Apple SDKs' plists has regressed. I would suggest you either upgrade Xcode, or file a bug with the MonoDevelop log file (found in ~/Library/Logs/MonoDevelop-3.0) attached.

Looks like MSVS 11.0 Beta spoiled a MSVS 10.0 installation

I ran into compilation problems with my MSVS 10 after installing MSVS 11Beta. Now, when I compile my C# Projects in MSVS 10 (Projects created in MSVS 10; Target framework: 3.5), I get errors MSB4216, MSB4028 with following text in output window:
1>Task "GenerateResource" skipped, due to false condition; ('%(EmbeddedResource.Type)' == 'Resx' and '%(EmbeddedResource.GenerateResource)' != 'false' and '$(GenerateResourceMSBuildRuntime)' != 'CLR2') was evaluated as ('Resx' == 'Resx' and '' != 'false' and 'CLR2' != 'CLR2').
1>Task "GenerateResource"
1> Launching task "GenerateResource" from assembly "Microsoft.Build.Tasks.v3.5, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" in an external task host with a runtime of "CLR2" and a process architecture of "x86".
1>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2199,5): error MSB4216: Could not run the "GenerateResource" task because we could not create or connect to a task host with runtime "CLR2" and architecture "x86". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NetFX 4.0 Tools\MSBuildTaskHost.exe" exists.
1>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2217,7): error MSB4028: The "GenerateResource" task's outputs could not be retrieved from the "FilesWritten" parameter. Object does not match target type.
1>Done executing task "GenerateResource" -- FAILED.
How can I fix these errors?
EDIT:
Mentioned file "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NetFX 4.0 Tools\MSBuildTaskHost.exe" exists.
C++ projects are compling without problems.
Reinstalling VS10 doesn't solve the problem.
This is GenerateResource task, that must compile resx-file, but generates an exception:
<!-- But we can't use those parameters if we're targeting 3.5, since we're using the 3.5 task -->
<GenerateResource
Sources="#(EmbeddedResource)"
UseSourcePath="$(UseSourcePath)"
References="#(ReferencePath)"
AdditionalInputs="$(MSBuildAllProjects)"
NeverLockTypeAssemblies="$(GenerateResourceNeverLockTypeAssemblies)"
StateFile="$(IntermediateOutputPath)$(MSBuildProjectFile).GenerateResource.Cache"
StronglyTypedClassName="%(EmbeddedResource.StronglyTypedClassName)"
StronglyTypedFileName="%(EmbeddedResource.StronglyTypedFileName)"
StronglyTypedLanguage="%(EmbeddedResource.StronglyTypedLanguage)"
StronglyTypedNamespace="%(EmbeddedResource.StronglyTypedNamespace)"
StronglyTypedManifestPrefix="%(EmbeddedResource.StronglyTypedManifestPrefix)"
PublicClass="%(EmbeddedResource.PublicClass)"
OutputResources="#(EmbeddedResource->'$(IntermediateOutputPath)%(ManifestResourceName).resources')"
MSBuildRuntime="$(GenerateResourceMSBuildRuntime)"
MSBuildArchitecture="$(GenerateResourceMSBuildArchitecture)"
Condition="'%(EmbeddedResource.Type)' == 'Resx' and '%(EmbeddedResource.GenerateResource)' != 'false' and '$(GenerateResourceMSBuildRuntime)' == 'CLR2'">
I tried to debug MSBuild script (.csproj). Just before the fatal GenerateResource task I checked all the properties and items. There was nothing about "8.0A" but only about "7.0A"
There is an ugly way to fix the problem: renaming folder "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A". I hate to accept this answer.
How long is your username?
It seems that there is a bug when the username is 20 characters long. If your username is 19 characters or less it works fine.
I have opened an issue on connect.
Edit:
Have you tried setting the environment variable DisableOutOfProcTaskHost to true as suggested in the connect issue, that worked for me.
A similar questin was asked on the MSDN forums. Did you reboot after installing VS11?
http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/7d955d96-ff73-47d3-8830-85ea321eb4ab
This issue occurred for me on my TFS 2010 build server after installing VS2010 and then installing .NET Framework 4.5. This allowed me to build .NET 4.5 projects but any VS2008 project targeting CLR2 (.NET 2.0 -3.5) I attempted to build would return the error. None of the suggestions on the handful of sites talking about this issue worked.
Rebooting - Did not fix the issue
Setting DisableOutOfProcTaskHost = true in an environment variable and also within the project file - Did not fix the issue
Username of my build account was already less than 20 characters
Renaming windows SDK folder - N/A since I did not have VS2012 and the 8.0A SDK installed... just .NET framework 4.5.
In any case, to fix this I uninstalled .NET 4.5, repaired VS2010, and then rebooted the build server. Now I am able to build VS2008 and VS2010 projects with no issues.
Luckily I no longer need to build .NET 4.5 projects as that team decided to go back to .NET 4.0.
Another possible fix is to change the target framework of your projects to .Net 4.0. It's not always a solution, but it certainly is a possibility if all else fails.
Worked for me: Removing the bin and obj folder for problematic folders and restarting the solution
In my case, I received that error message when trying to build a solution on a 32-bit Windows 7 machine. The way to resolve the error for me was to right-click on the project, choose properties, then go to the Build tab. In here I changed the "Platform target" from "Any CPU" to "x86". HTH
Setting Setting DisableOutOfProcTaskHost = true in an environment variable worked for me.

Categories