-
Notifications
You must be signed in to change notification settings - Fork 966
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.NET Core MSBuild is missing the LC task #1462
Comments
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. |
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. |
From @rainersigwald on Tuesday, August 1, 2017 7:22:55 PM The LC task wasn't ported to .NET Core because The best way to deal with this today is to use full-framework @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? |
From @rustyhann on Tuesday, August 1, 2017 7:52:23 PM 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. |
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. |
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. |
From @iainnicol on Thursday, November 29, 2018 10:22:47 AM
Makes sense. But does .NET Core 3's support of WinForms controls (on Windows) change things? |
From @rainersigwald on Thursday, November 29, 2018 4:07:02 PM
That's a good question. @merriemcgaw do you know if there are plans to bring |
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. |
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. |
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. |
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. |
From @livarcocc on Friday, February 8, 2019 9:43:28 PM Should we move this issue to the winforms repo? |
From @IrinaPykhova on Wednesday, April 3, 2019 1:48:54 PM
WPF uses the same licensing model |
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? |
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? |
Hi, any ETA on when this will be fixed? |
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. |
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. |
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? |
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. |
was lc.exe support added to Core 3.1? |
@LiorBanai I do not believe so. |
disable unit test until issue dotnet/winforms#1462 is fixed
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.
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 thank you for sharing. |
This comment has been minimized.
This comment has been minimized.
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. |
Right, sorry, wasn't paying enough attention. Yeah building licx in Desktop and embedding the result works, thanks. |
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 |
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?) |
@EamonHetherton Runtime: net472, SDK-Style .csproj files and try to build with dotnet build |
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
then build with "dotnet.exe build Solution.sln" |
From @merriemcgaw
|
This isn't going to be supported per dotnet/winforms#1462.
This isn't going to be supported per dotnet/winforms#1462.
@dennismaxjung @EamonHetherton Does not work for me, and I think I know why. When you put it in a Framework project as <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 The I hope this helps @dennismaxjung. |
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
Expected behavior
The project builds and the license information are compiled in the binaries
Actual behavior
The following error is raised:
Environment data
dotnet --info
output:Copied from original issue: dotnet/cli#6389
Copied from original issue: dotnet/msbuild#2006
The text was updated successfully, but these errors were encountered: