I have cloned a project to my computer using TFS, when I build the project I get this error :
Error 6 Task could not find "LC.exe" using the SdkToolsPath "" or the
registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v8.1A\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 searched the web but couldn't find a solution. I use VS 2013 and .NET 4.
How can I fix this? Thanks.
If you're using MSBuild.exe to build projects from the command line, you can pass TargetFrameworkSDKToolsDirectory as a parameter to avoid having to edit your .csproj files.
For example:
MSBuild.exe mysolution.sln /t:build /p:TargetFrameworkSDKToolsDirectory="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools"
It turns out you can specify the path to the SDK directly in the .csproj file:
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools</TargetFrameworkSDKToolsDirectory>
and the build found lc.exe that way.
So do a dir /s for lc.exe and use that path.
I previously expected to set this using <SdkToolsPath>, but that didn't work. In Microsoft.Common.targets, SdkToolsPath gets set from TargetFrameworkSDKToolsDirectory, so I tried that and it worked. (It would be nice if the variable name corresponded 1 to 1, but they don't.)
This is on Visual Studio 2015, and msbuild being called from ant.
I was having the same problem and resolved it by re-installing the Visual Studio.
http://msdn.microsoft.com/en-us/library/ha0k3c9f(v=vs.110).aspx
The License Compiler reads text files that contain licensing
information and produces a binary file that can be embedded in a
common language runtime executable as a resource. A .licx text file is
automatically generated or updated by the Windows Forms Designer
whenever a licensed control is added to the form. As part of
compilation, the project system will transform the .licx text file
into a .licenses binary resource that provides support for .NET
control licensing. The binary resource will then be embedded in the
project output. Cross compilation between 32-bit and 64-bit is not
supported when you use the License Compiler when building your
project. This is because the License Compiler has to load assemblies,
and loading 64-bit assemblies from a 32-bit application is not
allowed, and vice versa. In this case, use the License Compiler from
the command line to compile the license manually, and specify the
corresponding architecture. This tool is automatically installed with
Visual Studio. To run the tool, use the Developer Command Prompt (or
the Visual Studio Command Prompt in Windows 7). For more information,
see Visual Studio Command Prompt.
Related
I'm setting up Visual Studio Code to write and learn C#.
I'm not able to find and use the latest version of C# compiler with Visual Studio Code.
Enquiring enquiring my compiler version with the Visual Studio Code terminal command csc -langversion:? brings up the following error message:
csc : The term 'csc' is not recognized as the name of cmdlet,
function, script file, or operable program. Check the spelling of the
name, or if a path was included, verify that the path is correct and
try again.
My previous attempts in solving the problem
Having searched intensely, I have found out this:
When using Visual Studio, this problem doesn't even occur. Visual Studio apparently contains the necessary .NET SDK and compiler and uses it automatically.
I should locate the csc.exe file and set it as an environment variable path.
The only csc.exe files I find are located in the directory:
C:\Windows\Microsoft.NET\Framework64\v x.x.xxxxx with the latest being version being 4.0.30319.
All the instructions I could find suggested using this folder to be set as an environment variable path.
I do that. I now try again in Visual Studio Code: csc -langversion:?
Now I get the following message:
Microsoft (R) Visual C# Compiler version 4.8.4084.0 for C# 5
Copyright (C) Microsoft Corporation. All rights reserved.
This compiler is provided as part of the Microsoft (R) .NET Framework,
but only supports language versions up to C# 5, which is no longer the
latest version. For compilers that support newer versions of the C#
programming language, see
http://go.microsoft.com/fwlink/?LinkID=533240
warning CS2008: No source files specified error CS1617: Invalid option
'?' for /langversion; must be ISO-1, ISO-2, 3, 4, 5 or Default"
So the csc.exe I was referring and have set as an environment variable path is outdated. I would, however, like to get all the modern features of C# 9.
I tried again to find the latest compiler from the folder "C:\Program Files\dotnet", but I could only find a folder, "Roslyn", which, to my understanding, refers to the newest versions of csc. I couldn't find any csc.exe in these folders.
The solutions?
Now should I find the latest csc.exe supporting C# 9 from somewhere (where?) and set it up as an environmental variable path?
Or am I on the wrong track here?
Or is the only choice that I give up Visual Studio Code completely and switch to Visual Studio (I wouldn’t want to do that). But that can't be the only solution!
Background information
I am a total beginner to the world of coding.
I have installed the latest version of .NET SDK 5.0.302.
I have installed the following extensions in my Visual Studio Code instance:
C# (MS)
.NET Install Tool for Extension Authors (MS),
C# XML Documentation Comments (Keisuke Kato)
ilspy-vscode (SharpDevelop Team)
MSBuild project tools (tintoy)
REST Client (Huachao Mao)
You should use the dotnet command in your console to build and run a .NET 5 application.
Try to install the C# extension in your Visual Studio Code.
The crucial piece of findings:
Using statement:
#error version
produces detailed information about the compiler in use. It returned the same version number for the compiler as if I wouldn't have defined the Roslyn folder under the .vscode as PATH in the environment variables.
Therefore I think I can safely conclude this:
Visual Studio Code doesn't show you the current compiler with the call csc -langversion:? unless you add the aforementioned Roslyn folder under .vscode as a PATH on environmental variables.
However, it does seem that Visual Studio Code uses this particular compiler anyway, even though it doesn't formally recognise it. So the only thing that is really important is to install the latest .NET SDK.
I did the following and it worked.
I went to My Computer → Properties → Advanced System Settings → Environment Variables → double clicked on "Path" → Add new → pasted the directory where you can find csc.exe and clicked OK.
I restarted Visual Studio Code and it worked. The directory where I found csc.exe for me was:
C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.10-rel-29722-00\tools\csc
I have a build on TeamCity that packages a web project ready for later deployment, currently using MSBuild 2013. When I pushed some code recently I got build errors (due to the fact that I was using some C# 6 features) so I went to change the build configuration to use MSBuild 2015 instead and got this error:
[Error] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Transform\Microsoft.Web.Publishing.AspNetCompileMerge.targets(132, 5): Can't find the valid AspnetMergePath
This error has been mentioned in other questions before (such as here: VS 2012 Publish: Can't find the valid AspnetMergePath) but unfortunately none of the fixes mentioned in those questions have worked for me.
Things I have already tried or were already the case:
Web and WebApplication directories from local machine (at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0) have been copied up to build server (they've always been there)
Added
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\</TargetFrameworkSDKToolsDirectory> to
Microsoft.Web.Publishing.AspNetCompileMerge.targets file
Added /p:AspnetMergePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\" to MSBuild command
I'm at a bit of a loss with this one: pretty much the only thing I haven't tried is installing Visual Studio on the build server, but I'd really like to avoid that if I can (because I think it's ridiculous that you should have to install a full IDE on a CI server!).
Some further info:
everything continues to work just fine if you switch the build back to MSBuild 2013 (although, obviously, we don't want to get stuck in the past)
we have a number of other pure compilation builds that are running against MSBuild 2015 with no errors
Both the second and the third solution originally proposed on VS 2012 Publish: Can't find the valid AspnetMergePath actually do work, but the right version of the SDK tools has to be provided.
The original article (VS 2012 Publish: Can't find the valid AspnetMergePath) was written in 2013 and covers the Visual Studio 2012. The aspnet_merge.exe that supports C# 6.0 and .NET 4.6 is not the one that is found under the path "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\".
In order to get the third solution work, use the following path instead "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\".
In oder words, adding /p:AspnetMergePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\" to MSBuild command solves the problem.
My team had exactly the same issue as the one you are describing and adding this parameter to the MSBuild step immediately fixed it. (I assume of course that you have the NETFX 4.6 version of the tools on your build machine.)
As a side note, since you said that you use Team City - instead of adding the above parameter directly as a command line parameter, you can use the Team City recommended and configure the corresponding build parameter.
The accepted answer is just symptom treatment and doesn't address the underlying issue. Please run MSBuild with diagnostic logging. If you look at the Microsoft.Web.Publishing.AspNetCompileMerge.targets you will see that it attempts to concatenate TargetFrameworkSDKToolsDirectory with AspnetMergeName. If you search in your MSBuild log, you will find that TargetFrameworkSDKToolsDirectory is empty. TargetFrameworkSDKToolsDirectory is build from TargetFrameworkSDKDirectory which is also empty.
That is what you need to fix. In my case:
Install the Windows 7.1 SDK (using this workaround on Windows Server 2016).
In VS2017 the path is determined based on /configuration/msbuildToolsets/toolset/property[#name="FrameworkSDKRoot] which is in my case Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1#InstallationFolder. In my case this node was only available in the WOW6432Node, it needs to be available in the 64-bit registry too. You need to copy the node to the equivalent location in the 64-bit registry.
I have a few classes with the same namespace, and I want to put all of them in a dll file, and use it in other places.
I read the guide on Microsoft's website:
http://msdn.microsoft.com/en-us/library/3707x96z(v=vs.80).aspx
They suggested this:
To build the file [myDllName].DLL, compile the two files [myClass1].cs and
[myClass2].cs using the following command line:
csc /target:library /out:[myDllName].DLL [myClass1].cs [myClass2].cs
I wrote it in a cmd window and got an error that there is no such command as csc.
Plus, how it will find my files without a path?
So what is the right way of doing it? Where should I write it?
I saw some posts here with Library classes.. but not sure how it can help me.
My classes are in a different solution, and I just want to use it as an external dll, and not within the same solution.
In this case, Microsoft's guide seems perfect, if it will work.
If you use the Visual Studio Command Prompt window, all the necessary environment variables are set for you. In Windows 7, you can access that window from the Start menu by opening the Microsoft Visual Studio Version\Visual Studio Tools folder. In Windows 8, the Visual Studio Command Prompt is called the Developer Command Prompt for VS2012, and you can find it by searching from the Start screen.
source
You can run the vsvars batch file from a command prompt and it will set paths for you, for that instance of cmd.exe
Mine is here:
>"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\vsvars32.bat"
Why don't you just create a separate 'Class Library' project in your solution in Visual Studio?
You can than easily add it as a project reference to all other projects that need it.
You can create Solution Folders in VS to logically group projects.
Make sure csc.exe is in your PATH environment variable.
You should have a vsvars32.bat that was installed with Visual Studio. You can run that to automatically add it to the path, or dig down in regedit to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP
Look through the subtrees in there for your framework version, and for an InstallPath key. That should tell you what directory to look in.
You can then use that, and:
WHERE /r "the_directory_you_found" csc.exe
to find the path. Add that to your system environment variables, and you should be able to find it.
As for the path of the class files, either run the command from the directory they're in, or specify the path when specifying the class files.
If you have Visual Studio installed, you could try creating a 'Class Library' project; Or you can run csc.exe by Launching "Visual Studio Command Prompt".
If you don't have Visual Studio installed but have .net framework installed. You can run csc.exe from the framework installation directory.
Installation directory path for .net Framework 4.0 :
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319
What I'm trying to do
I currently have a project file that contains a single EF 5 Model with the .edmx configured to embed the metadata into the output assembly.
If I run a local package via Visual Studio 2012, the produced assemblies contain the correct resources. Manually running package through MSBuild also correctly embeds the resources in the assembly:
msbuild web.csproj /t:Package /p:Configuration=Release
When I manually inspect the assembly generated by Visual Studio or by the MSBuild package step with dotPeek, I can confirm that the package contains the .csdl, .ssdl and .msl resources.
The actual problem
I have on hand a build server that is running Microsoft Windows Server 2012 and Visual Studio 2012. If I manually run MSBuild via the Visual Studio 2012 Command Prompt, using the same exact command line as above, then an assembly is generated that does not contain the resources embedded.
Why are my EF metadata files not being embedded when I perform automated packages via MSBuild?
Simple Self Contained Correct Example
A SSCCE which demonstrates the workaround may be found here. The example contains the exact steps required to reproduce the error in the readme.txt.
Using your example, on Windows 8 + VS2012 installed, I was able to generate package using Package.bat and all generated assemblies are contain the all EF metadata files.
In the Readme.txt you are mention the MSDeploy
4) Run MSDeploy /t:package on the project
From your question looks like you have issues with MSBuild.
Could you verify that you don't have old TestEntityEdmx.Hackaround.dll sitting in the TestEntityEdmx\obj\Release... folder when you run build.
I want to write to visual studio output window in my add in. I found a code from
How do I write to the Visual Studio Output Window in My Custom Tool?
But I can't add a reference to IVsOutputWindow.
There is no any namespace like Microsoft.VisualStudio.Shell.Interop
and also no dll. How should I fix this problem
Thank you.
It sounds like you're having trouble locating the IVsOutputWindow interface. If so here is the information on that type
Namespace: Microsoft.VisualStudio.Shell.Interop
DLL: Microsoft.VisualStudio.Shell.Interop
If the SDK is install on your machine the DLL will be located in the following directory
C:\Program Files (x86)\Microsoft Visual Studio 2010 SDK\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.Shell.Interop.dll
The top 2 directories may change though based on the operating system and version of the SDK you are using. If this doesn't work please let me know the SDK version you are using and I'll try and point you to the correct path.
I found that I had to actually download and install the Visual Studio SDK - it's a separate download that's not included with Visual Studio itself. Once installed, I restarted Visual Studio, and the necessary assemblies were listed when I went to add references to my project.