.NET Core MSBuild is missing the LC task

[livarcocc]

From @livarcocc on Monday, April 24, 2017 5:08:10 PM

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: 37224c9917

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

Copied from original issue: dotnet/msbuild#2006

[livarcocc]

From @livarcocc on Monday, April 24, 2017 5:08:10 PM

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.

[livarcocc]

From @rustyhann on Tuesday, August 1, 2017 7:15:13 PM

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.

[livarcocc]

From @rainersigwald on Tuesday, August 1, 2017 7:22:55 PM

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?

[livarcocc]

From @rustyhann on Tuesday, August 1, 2017 7:52:23 PM

@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.

[livarcocc]

From @vanthao on Tuesday, October 3, 2017 7:09:28 PM

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

[livarcocc]

From @rustyhann on Tuesday, October 10, 2017 1:47:24 AM

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.

[livarcocc]

From @iainnicol on Thursday, November 29, 2018 10:22:47 AM

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?

[livarcocc]

From @rainersigwald on Thursday, November 29, 2018 4:07:02 PM

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?

[livarcocc]

From @iainnicol on Thursday, November 29, 2018 5:04:40 PM

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.

[livarcocc]

From @merriemcgaw on Thursday, November 29, 2018 9:07:42 PM

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

[livarcocc]

From @ericstj on Friday, February 8, 2019 2:44:48 PM

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.

[livarcocc]

From @sansjunk on Friday, February 8, 2019 2:52:24 PM

@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.

[livarcocc]

From @merriemcgaw on Friday, February 8, 2019 8:53:41 PM

@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]

From @livarcocc on Friday, February 8, 2019 9:43:28 PM

Should we move this issue to the winforms repo?

[livarcocc]

From @IrinaPykhova on Wednesday, April 3, 2019 1:48:54 PM

Should we move this issue to the winforms repo?

WPF uses the same licensing model

[livarcocc]

From @jroessel on Wednesday, July 24, 2019 8:04:49 AM

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

[merriemcgaw]

We do not have this on our radar for the 3.0 release. @OliaG , when will we be taking a look at how we support licensing for 3.0?

[sansjunk]

Hi, any ETA on when this will be fixed?

[weltkante]

They are working on it (dotnet/project-system#4938 and dotnet/sdk#3631), licx is supposed to work again already, but the LC.exe part is still missing I think. I doubt this will be in 3.0 release considering that this is only a week from now and they still need to port LC.exe to .NET Core.

[weltkante]

dotnet/sdk#3631 wants this in 3.1, so this issue being on Future is conflicting. If licensing is going to be supported in 3.1 it probably needs to be picked up soonish.

[weltkante]

Any updates on what is happening? dotnet/project-system#4938 had suggestions how to improve handling of licensing post-3.1 and I'd like to create a follow-up issue for that. I was waiting because it was unclear which repo is going to pick up LC.exe. Any suggestion how to proceed? Should I wait for 3.1 release when licensing is (hopefully) resolved?

[OliaG]

cc @terrajobst since he'll be working on licensing story for .NET Core.

As of now we are not planning on porting LC.exe to .NET Core.

[LiorBanai]

was lc.exe support added to Core 3.1?
I'm still missing ability to build via Github workflow that target core 3.1:
https://github.com/Analogy-LogViewer/Analogy.LogViewer/actions

[merriemcgaw]

@LiorBanai I do not believe so.
@OliaG or @terrajobst, do we have more info about the licensing story to share?

[EamonHetherton]

For anyone is the same boat I am currently in with migrating older code containing components that use the license.licx runtime licensing model towards dotnet core and wanting to use "dotnet build" here is the workaround that I am using.

Caveat; it works for me, YMMV.

1. Ensure your licenses.licx file is included in your project with BuildAction "EmbeddedResource"
2. Build project using visual studio or msbuild
3. Find "[projectname].exe.licenses" file in obj folder and copy to root of exe project and include as EmbeddedResource
4. Change licenses.licx to BuildAction "None" to avoid "error MSB4062: The "Microsoft.Build.Tasks.LC" task could not be loaded"

now you can build using dotnet build without getting "error MSB4062: The "Microsoft.Build.Tasks.LC" task could not be loaded from the assembly Microsoft.Build.Tasks.Core" and with proper runtime licences embedded.

This may become tedious if you are regularly changing the components/versions etc. and your licenses.licx files changes but for me the components using the licenses.licx model have not changed in a number of years so neither has my licenses.licx file and I don't expect it to change anytime soon, more likely they'll eventually be replaced by something that does not need licenses.licx entries.

[RussKie]

@EamonHetherton thank you for sharing.

[EamonHetherton]

step 3) is the magic....

that file is essentially the licenses.licx transformed by LC.exe I believe. In any case, including it makes my project run correctly when building using dotnet build. without it I get runtime component license exceptions.

[weltkante]

Right, sorry, wasn't paying enough attention. Yeah building licx in Desktop and embedding the result works, thanks.

[ericstj]

This change in runtime will deprecate the format written by the desktop tool: dotnet/runtime#48527

Without a new tool that writes the new format established in that PR there will be no way to use Licensing in .NET 6 (without reenabling BinaryFormatter, at least). @pgovind

[weltkante]

There already is no (working) licensing in .NET Core, some fractions of the old infrastructure remain working, but as a whole it does not work even now. Its a longstanding open issue. Considering its not even officially possible yet to develop custom controls its not a major issue.

The deprecation of BF will be much more catastrophic to the Clipboard and Drag and Drop systems though if/when it gets deprecated there as well, these require it and I'm not aware of a plan for a replacement. (Though maybe there are internal plans not made public yet?)

[dennismaxjung]

For anyone is the same boat I am currently in with migrating older code containing components that use the license.licx runtime licensing model towards dotnet core and wanting to use "dotnet build" here is the workaround that I am using.

Caveat; it works for me, YMMV.

1. Ensure your licenses.licx file is included in your project with BuildAction "EmbeddedResource"
2. Build project using visual studio or msbuild
3. Find "[projectname].exe.licenses" file in obj folder and copy to root of exe project and include as EmbeddedResource
4. Change licenses.licx to BuildAction "None" to avoid "error MSB4062: The "Microsoft.Build.Tasks.LC" task could not be loaded"

now you can build using dotnet build without getting "error MSB4062: The "Microsoft.Build.Tasks.LC" task could not be loaded from the assembly Microsoft.Build.Tasks.Core" and with proper runtime licences embedded.

This may become tedious if you are regularly changing the components/versions etc. and your licenses.licx files changes but for me the components using the licenses.licx model have not changed in a number of years so neither has my licenses.licx file and I don't expect it to change anytime soon, more likely they'll eventually be replaced by something that does not need licenses.licx entries.

@EamonHetherton
Does this still works ? I've some problems with this workaround. I've added the gerneated .licenses file as embedded ressource but on runtime it says it is still not licenced. Are there any things besides this i could missed ?

Runtime: net472, SDK-Style .csproj files and try to build with dotnet build

[EamonHetherton]

Still working here. Targeting .NET Framework 4.8 using dotnet.exe to build, only thing a little different is that I've made the original licenses.licx file DependentUpon on the .licenses file

<ItemGroup> <EmbeddedResource Include="application.exe.licenses" /> <None Include="licenses.licx"> <DependentUpon>application.exe.licenses</DependentUpon> </None> </ItemGroup>

then build with "dotnet.exe build Solution.sln"

[RussKie]

#3316 (comment)

From @merriemcgaw

There are no plans to implement the licx file mechanism for licensing. The current thinking internally is that most software vendors are creating their own licensing mechanism, and that the licx file method was not adequate for most modern scenarios. The recommendation is to either invest in a cloud-based licensing approach or create a system specific to your component and your component needs. Microsoft does not have plans to invest in a licensing model provided by Microsoft in .NET. If you have any questions, you can reach out to me or @OliaG directly, and we'd be happy to pass along feedback up our management chain.

[cbenard]

Still working here. Targeting .NET Framework 4.8 using dotnet.exe to build, only thing a little different is that I've made the original licenses.licx file DependentUpon on the .licenses file

@dennismaxjung @EamonHetherton Does not work for me, and I think I know why. When you put it in a Framework project as something.dll.licenses, the root namespace is prepended so you get something.something.dll.licenses which doesn't match the original name. The solution is to do this:

<ItemGroup>
  <!-- We are using a pre-compiled licenses.licx with a .licenses file (from obj output of VS build)
       so that we can use dotnet build. LC.exe is deprecated for post .NET Framework -->
  <None Include="licenses.licx">
    <DependentUpon>licenses.precompiled.licenses</DependentUpon>
  </None>
  <EmbeddedResource Include="licenses.precompiled.licenses">
    <LogicalName>Something.exe.licenses</LogicalName>
  </EmbeddedResource>
</ItemGroup>

I extracted the resource ending in licenses using dnSpy from one built by the build server get the correct licensing and saved it as licenses.precompiled.licenses in each project that needed it and this appears to work.

The <LogicalName> causes the resource to be written correctly. I'm guessing you either have an empty RootNamespace or the differences might be related to the breaking change Resource manifest file name change.

I hope this helps @dennismaxjung.