.NET Core MSBuild is missing the LC task

[livarcocc]

From @alienisty on April 24, 2017 1:58

Steps to reproduce

Just create a project with a licenses.licx file definition and build the project with

dotnet build project.csproj

Expected behavior

The project builds and the license information are compiled in the binaries

Actual behavior

The following error is raised:

C:\Program Files\dotnet\sdk\1.0.3\Microsoft.Common.CurrentVersion.targets(2977,5): error MSB4062: The "Microsoft.Build.Tasks.LC" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Confirm that the decl
aration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
0 Warning(s)
1 Error(s)

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.3)

Product Information:
Version: 1.0.3
Commit SHA-1 hash: 37224c9

Runtime Environment:
OS Name: Windows
OS Version: 6.3.9600
OS Platform: Windows
RID: win81-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.3

Copied from original issue: dotnet/cli#6389

[livarcocc]

From @alienisty on April 24, 2017 2:1

Note that building the project with MSBuild provided with Visual Studio 2017 builds the project fine.
I also checked the core tasks dlls from the donet core SDK and VS2017 and the one from the dotnet core sdk is actually missing the LC task, while the VS2017 one has it.

[rustyhann]

I'm also experiencing this problem. I tried pointing our build script to MSBuild.exe in the Visual Studio installation path (..\Program Files (x86)..) but I still get this error.

[rainersigwald]

The LC task wasn't ported to .NET Core because lc.exe isn't available in a cross-platform version (that I know of, anyway). The task just calls the executable, so it wouldn't work on non-Windows platforms.

The best way to deal with this today is to use full-framework msbuild.exe, which does have the task.

@rustyhann, you're saying that's not working for you, which is unexpected. How exactly are you invoking the build? Could you share a diagnostic-level build log?

[rustyhann]

@rainersigwald

Thank you for the quick reply,

I'm working on generating a diagnostic log now. While that's running I can provide some background on our project.

We started the project as a .NET Core project (using dotnet new), then changed the target to "net462". We're doing this as a way to move to .NET Core completely while we migrate our legacy libraries. The full path we're using in our build script is:

"'C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe'"

We switched to this when we migrated to Visual Studio 2017. It solved most of our build issues until we ran into the lc.exe error.

I'll post the diagnostic build log when it's finished.

--Update

I've stored the file in OneDrive and sent a link.

[vanthao]

When this issue will be fixed? I faced the same issue with Teletik license file.

[rustyhann]

You can work around this by building with MSBuild and deploying with MSDeploy. The .Net Core tools will not work. The root issue for our scenario was dotnet publish was calling dotnet build. The no-compile option was deprecated in dotnet build. Even if we used MSBuild before calling dotnet publish we still had the issue. Switching to MSDeploy was the answer.

[iainnicol]

The LC task wasn't ported to .NET Core because lc.exe isn't available in a cross-platform version (that I know of, anyway). The task just calls the executable, so it wouldn't work on non-Windows platforms.

Makes sense. But does .NET Core 3's support of WinForms controls (on Windows) change things?

[rainersigwald]

Makes sense. But does .NET Core 3's support of WinForms controls (on Windows) change things?

That's a good question. @merriemcgaw do you know if there are plans to bring lc.exe to core?

[iainnicol]

Thanks for forwarding on the question.

Note that even if the "dotnet" command does not get support, a tweak to the (.NET Framework) msbuild task would still be useful. Similarly to #2836, (.NET Framework) msbuild passes giant command line arguments to lc.exe, when targetting netcoreapp3.0.

[merriemcgaw]

I know it's been discussed, but I don't know where the discussions have landed yet.

[ericstj]

Running desktop lc.exe on core assemblies is busted. See https://github.com/dotnet/corefx/issues/24200#issuecomment-461803927. I think this needs to be fixed. We have had a few customers ask for the licensing functionality in netcore 3.0.

[sansjunk]

@ericstj Thanks for pointing to the issue I faced. I'd like to add we need this not just for licensing components/controls but also plain class libraries. In fact right now for .NET core we are trying this only for the plain class library case.

[merriemcgaw]

@sansjunk thanks for the scenario explanation. I will be working with my team to make a plan for when/how we migrate lc.exe support to Core.

[livarcocc]

Should we move this issue to the winforms repo?

[IrinaPykhova]

Should we move this issue to the winforms repo?

WPF uses the same licensing model

[jroessel]

Is this issue expected to be fixed for the final .NET Core 3.0 release?

[livarcocc]

This issue was moved to dotnet/winforms#1462