MSBuild only errors on a handful of projects - c#

We have migrated to TFS2012 and VS2012 with an existing solution. My old build controller and TFS used to be on Windows 7, however this server for TFS2012 and our build controller is now Windows 8. The build is giving me the following error:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets
(2401): Task could not find "LC.exe" using the SdkToolsPath "" or the
registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86". Make sure the
SdkToolsPath is set and the tool exists in the correct processor
specific location under the SdkToolsPath and that the Microsoft
Windows SDK is installed
I have seen that a potential fix could be this however the error above is only occurring in specific projects. I thought that this could be down to the .NET framework version, however most projects are on the same version as other projects.
I then did a compare of the project files and noticed that the following attribute was a lower value than a project that worked.
<OldToolsVersion>2.0</OldToolsVersion>
So I updated this to version 4.0 and I still have no luck. Has anyone else experienced this? Is there a work around which doesn't involve me any installations? There must be a setting of some sort that is different as some projects do build and some do not...
TIA.

Guys you know really simple solution. go to asp.net and install the asp.net and tools from downloads page.
htp://www.asp.net/downloads
and every thing will be set and working.

Related

Creating an ASP.NET Core project

I want to create an Asp.net Core project with Visual Studio 2017 Community but the Solutions explorer says that I have (0 projects).
I tried selecting an empty project, web application, web application (Model-View-Controller) but the Solution explorer still displays (0 projects).
When I go-to Debug I see the "Attach to Process" option. There is no option to start of course since I have no projects.
What could be the issue?
Have you installed everything correctly? To verify this, open a normal cmd and just type 'dotnet'
Only if the command runs, printing out information about how to use dotnet, you're good to go.
Have you installed the correct .NET SDK? What version of it? Make sure the version is compatible with the version of visual studio you have installed.
Follow this link for step by step setup instructions:
https://www.c-sharpcorner.com/article/getting-started-with-net-core-on-visual-studio-2017/
This could be the same problem, but I had the same issue during College once but this time I had the support for the web components, so I went back to the installation and repaired it. It downloaded the missing files and it worked again and it took a while.
Let me know if that works or not.

Sitecore Courier set up issues

I am trying to configure a local instance of Sitecore Courier tool in order to compare and get the differences between master and web databases. From the online tutorial it's seems pretty easy to configure but when I'm trying to run the WebRunner project from solution (https://github.com/adoprog/Sitecore-Courier) I'm getting some weird errors in the console.
Also did the extra configs from here: https://libraries.io/github/adoprog/Sitecore-Courier
Is there someone who can help please?
Cheers
Looks like Sitecore Courier uses C# 6 language features. That is why you are getting build errors. And Editbin.exe could not patch executable that does not exist. Try to install latest C# compiler via Nuget to fix this problem:
Install-Package Microsoft.Net.Compilers
or update you Visual Studio to 2015+ version.

TFS Build Issues With Multiple Versions of the Same Assembly in Different Projects

I keep running into an issue with our TFS build server. I've got 2 projects (both in the same solution), 1 is a WebForms project, running .Net 4.0. The second is an ASP .Net MVC5 project running .Net 4.5. There is also a Silverlight project, but the problem is reproducible with just the first two.
Both of these projects use NuGet packages for various libraries. Sometimes there are different assemblies within a package for their respective environments. A .Net 4.0, 4.5, SL assembly, etc.
The build server seems to dump all of the libraries required into a single folder, then pulls from that to build the solution. This causes problems in many cases, with the wrong project getting the wrong assembly version. This does not occur locally, only on the build server. I can't figure out what I need to do to keep this from happening. Any ideas?
Yes, I hate this standard behavior, but TFS will output everything to the same folder by default, and then you will get various errors depending on which order msbuild compiles your projects if you have references with the same name or even project outputs with the same name.
The easiest workaround is to use the AsConfigured option on the Process tab, '2. Build' -> 'Output location' of the build definition window. This keeps your normal source structure intact, but I think you will lose support for automatically dropped outputs (i.e. you will have to provide a script to do that yourself). If you are only using TFS Build for validation, this is the cleanest approach.
You can also use the PerProject setting and split up your projects into two distinct solutions, perhaps suffixed by platform (we've done that numerous times in our company). Then, you specify both solutions to the build process and it will create two separate folders in the output, one for each solution.
This is all assuming you are using TFS 2013. In TFS2012, there is a similar option but it is in '3. Advanced' -> 'Solution Specific Build Outputs'. You will probably have to go this route if you are using TFS2012 or you will need to modify the default workflow yourself to add your own logic.
EDIT:
From your comment to the other poster I see you are using TFS 2010. Well... I think this was absolutely not supported at that time, I remember having similar problems, but we upgraded to TFS 2012 and all was well.
I think your only option is to either create two separate build definitions and build each solution that way, or you will need to checkout the xaml workflow and edit it with your own logic. Perhaps downloading the TFS2012 template and "porting" it to TFS2010 would be a better approach since at least you would not be reinventing the wheel that way.

Add FreeImage .NET to solution

I have followed the posts on this, but i am still not getting a few steps. I am new to C#, and that is probably the issue. I would love a little help (I have been banging on this all day).
I can open the FreeImage.NET solution (Win7 64 bit machine btw) in Visual Studio. This post says i need to Build it to get the C# dll. When i build it, i get hundreds of errors "type or namespace 'Name' could not be found".
Does it need the C++ DDL added first? I dragged and dropped it onto the solution, but still the errors.
Am i doing something simple and wrong?
Specifically what i am trying to do is add FreeImage to project in C# Visual Studio Express 2012.
Thanks,
Dan
After downloading the version of FreeImage.NET , I opened the following VS2005 Solution File in VS2012.(Thats the only one I have)
FreeImage3154\FreeImage\Wrapper\FreeImage.NET\cs\FreeImage.NET.2005.sln
After upgrading the project and building it for the first time, I saw around 491 errors. If you open the references of the UnitTest.2005 project, you will see that the nunit.framework assembly is missing. If you have nuget installed , in VS2012 you can
Right Click references > Manage NuGet Packages > Search for NUnit and install it.
In the image below we see that the nunit.framework assembly is correctly linked.
After doing this there were only 50 errors remaining and they were all because the Xml Documentation file checks were enabled. You can disable this check as shown below in the Library.2005 project.
Build again, and it should succeed.
NOTE: The FreeImage website provides only a 32-bit version of the DLL, thus to use this DLL you will have to ensure that you set your project version to 32-bit. To obtain a 64-bit version of the FreeImage DLL you will have o download their source code project and manually do a 64-bit build as show in this blog.

Failing Build because it can't find AL.exe

Here's an interesting problem that really has me scratching my head. I have a project that's being built in TeamCity. It's been working fine until a developer added a resource file to one of the projects with some strings for another locale. He's added the .resx file under the Properties folder next to the default one. Here's the error message from the build log:
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2105, 9):
error MSB3091: Task failed because "AL.exe" was not found, or the correct
Microsoft Windows SDK is not installed. The task is looking for "AL.exe" in the "bin"
subdirectory beneath the location specified in the InstallationFolder value
of the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A.
You may be able to solve the problem by doing one of the following:
1) Install the Microsoft Windows SDK for Windows Server 2008 and .NET Framework 3.5.
2) Install Visual Studio 2008.
3) Manually set the above registry key to the correct location.
4) Pass the correct location into the "ToolPath" parameter of the task.
There are a number of things here that I can't work out.
- How come it can find AL.exe for the default .resx file but not for this new one?
- Why's it looking in a registry key that looks Vista-specific, when the build is running on Server 2003?
Any ideas?
Problem solved by installing Windows SDK for Windows Server 2008 and .NET Framework 3.5 SP1.
I don't understand how MSBuild got out of step with its tools, perhaps I never will discover the reason, but installing that SDK fixed the problem for me.
Check msbuild from x86 is used. There should be an option in TeamCity build runner.
Was VS2008 installed on the machine?
Make sure the Windows SDK is completely installed on the server. AL.exe (Assembly Linker) is included with the .NET SDK (not the runtime).
(I have the same problem on my TFS server with ClickOnce, but too lazy to fix)

Categories

Resources