You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Aaron Meyers <Aa...@microsoft.com.INVALID> on 2019/07/05 22:15:45 UTC
Build error on LuceneDocsPlugin: target "pack" does not exist
Hi all,
I'm trying to build the current Lucene.Net sources locally and I'm running into the following build error:
C:\Data\github\lucenenet\src\docs\LuceneDocsPlugins\LuceneDocsPlugins\LuceneDocsPlugins.csproj : error MSB4057: The targ
et "pack" does not exist in the project.
Error: 7/5/2019 3:00:22 PM:
+ ~~~~~& dotnet.exe pack $project --configuration $Configuration --output $nuget_package_directory --no
-build --include.symbols /p:PackageVersion=$packageVersion
I've poked around a little bit and haven't figured out what is going on - has anyone else run into this?
My machine has multiple versions of VS (2015/2017/2019) and .NET Core SDKs (2.0 through 3.0 preview) so it might have something to do with that. It was trying to build using the 3.0 preview SDK which overrode with global.json in the lucenenet repo root but no effect on this build error.
Thanks!
Aaron Meyers
Principal Software Engineer
Microsoft Power BI
RE: Version.proj
Posted by Shad Storhaug <sh...@shadstorhaug.com>.
Chris,
I have pushed the fix to the master branch. Let me know if you have any more issues.
Thanks,
Shad
-----Original Message-----
From: Shad Storhaug <sh...@shadstorhaug.com>
Sent: Sunday, July 14, 2019 11:20 PM
To: dev@lucenenet.apache.org
Subject: RE: Version.proj
Like I said, moving the settings into the root Directory.Build.props (https://github.com/apache/lucenenet/blob/master/Directory.Build.props) would be the way to go. The Directory.Build.props at the repo root is imported automatically by all of the projects. If the settings were moved there, then the Version.proj file could be deleted and explicit imports for that file can be removed.
But the build script will also have to be updated
https://github.com/apache/lucenenet/blob/master/build/build.ps1#L253
https://github.com/apache/lucenenet/blob/master/build/build.ps1#L29
I am not sure why that is in there twice, but I recall there was a lot of chicken and egg stuff going on with defaulting PSake parameters. They should probably both be updated (dupe to remain) to keep the build working.
Also, Version.proj is referenced in the solution file (https://github.com/apache/lucenenet/blob/master/Lucene.Net.sln#L37), it should be removed there as well.
I will accept a PR if you want to make that change now.
It does surprise me a bit that Version.proj is toxic and TestTargetFrameworks.proj is not, though. Maybe Version.proj is a reserved name or something. Perhaps TestTargetFrameworks.proj should be renamed TestTargetFrameworks.props to be on the safe side.
-----Original Message-----
From: Chris Moschini <ch...@brass9.com>
Sent: Sunday, July 14, 2019 10:59 PM
To: dev@lucenenet.apache.org
Subject: Re: Version.proj
I'm using the latest version of Visual Studio 2019. I'm aware of the other imports but as you note that don't cause any problems. The Version.proj however breaks everything and the break is pretty bad. You basically have to go in and edit csproj manually and remove it, which of course is going to drag you away from upstream and make it hard for new potential devs to contribute.
Is there any harm in getting rid of it?
Could we consider changing the extension to something like a .txt or something so it doesn't freak out? Or some way to make it optional?
On Sun, Jul 14, 2019, 11:32 AM Shad Storhaug <sh...@shadstorhaug.com> wrote:
> Chris,
>
> Version.proj is a dependency of the build.ps1 build script, which was
> added before the last beta release in 2017. It is essentially the
> default version that will be used if you do a local build, and the
> major and minor version are parsed out of that file when certain
> parameters are used when doing a CI build.
>
> I noticed some weirdness when I was working on another project when
> trying to import a project file with a custom name in Visual Studio
> 2019, such as .proj. Apparently, Microsoft decided to lock it down so
> that the only valid extensions are .props and .targets (
> https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2019).
> However, when I opened Lucene.Net in Visual Studio 2019 a few weeks
> later it worked fine.
>
> I suspect that enough people complained that Microsoft updated Visual
> Studio to allow custom file extensions again. Try upgrading Visual
> Studio if you don't have the latest version.
>
> There are a few other project files that are imported the same way:
>
> build\Dependencies.props - All of the NuGet PackageReference versions
> are here build\NuGet.props - NuGet properties common to most projects
> build\TestReferences.Common.props - NuGet PackageReferences that are
> shared between all test projects TestTargetFramework.proj - This is
> where you can set the TargetFramework to run tests on. Still looking
> for an alternative, see:
> https://stackoverflow.com/q/43554028
>
> Are you seeing the problem with those project imports as well? I don't
> mind changing it, it is just a matter of working out what change will
> fix the problem entirely. I was thinking about rolling the
> Version.proj settings into the root Directory.Build.props file anyway.
>
> Another possibility is that the Directory.Build.props file at the
> level of the project folders is missing from your system (not sure how
> that could happen, but maybe). The $(SolutionDir) MSBuild property is
> only valid when doing IDE builds. We patch it in a few of those files
> (they exist at a few different directory levels) so it will work
> whether in the IDE or command line. If you are missing the file, then
> the resolution of Version.proj could fail.
>
> Regards,
> Shad
>
>
>
> -----Original Message-----
> From: Chris Moschini <ch...@brass9.com>
> Sent: Sunday, July 14, 2019 8:48 PM
> To: dev@lucenenet.apache.org
> Subject: Version.proj
>
> The Lucene.Net projects added a dependency on an import:
>
> <Import Project="$(SolutionDir)Version.proj" />
>
> Sometime around the end of last year. Is there any documentation on
> what this Version.proj is supposed to be, or contain?
>
> We don't use such a proj in our Solutions, and pulling latest has
> caused all our builds to fail. Simply commenting out this line is a
> crude but effective way to prevent killing our builds here, but I have
> to suspect it's going to cause other problems by not having it...
>
RE: Version.proj
Posted by Shad Storhaug <sh...@shadstorhaug.com>.
Like I said, moving the settings into the root Directory.Build.props (https://github.com/apache/lucenenet/blob/master/Directory.Build.props) would be the way to go. The Directory.Build.props at the repo root is imported automatically by all of the projects. If the settings were moved there, then the Version.proj file could be deleted and explicit imports for that file can be removed.
But the build script will also have to be updated
https://github.com/apache/lucenenet/blob/master/build/build.ps1#L253
https://github.com/apache/lucenenet/blob/master/build/build.ps1#L29
I am not sure why that is in there twice, but I recall there was a lot of chicken and egg stuff going on with defaulting PSake parameters. They should probably both be updated (dupe to remain) to keep the build working.
Also, Version.proj is referenced in the solution file (https://github.com/apache/lucenenet/blob/master/Lucene.Net.sln#L37), it should be removed there as well.
I will accept a PR if you want to make that change now.
It does surprise me a bit that Version.proj is toxic and TestTargetFrameworks.proj is not, though. Maybe Version.proj is a reserved name or something. Perhaps TestTargetFrameworks.proj should be renamed TestTargetFrameworks.props to be on the safe side.
-----Original Message-----
From: Chris Moschini <ch...@brass9.com>
Sent: Sunday, July 14, 2019 10:59 PM
To: dev@lucenenet.apache.org
Subject: Re: Version.proj
I'm using the latest version of Visual Studio 2019. I'm aware of the other imports but as you note that don't cause any problems. The Version.proj however breaks everything and the break is pretty bad. You basically have to go in and edit csproj manually and remove it, which of course is going to drag you away from upstream and make it hard for new potential devs to contribute.
Is there any harm in getting rid of it?
Could we consider changing the extension to something like a .txt or something so it doesn't freak out? Or some way to make it optional?
On Sun, Jul 14, 2019, 11:32 AM Shad Storhaug <sh...@shadstorhaug.com> wrote:
> Chris,
>
> Version.proj is a dependency of the build.ps1 build script, which was
> added before the last beta release in 2017. It is essentially the
> default version that will be used if you do a local build, and the
> major and minor version are parsed out of that file when certain
> parameters are used when doing a CI build.
>
> I noticed some weirdness when I was working on another project when
> trying to import a project file with a custom name in Visual Studio
> 2019, such as .proj. Apparently, Microsoft decided to lock it down so
> that the only valid extensions are .props and .targets (
> https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2019).
> However, when I opened Lucene.Net in Visual Studio 2019 a few weeks
> later it worked fine.
>
> I suspect that enough people complained that Microsoft updated Visual
> Studio to allow custom file extensions again. Try upgrading Visual
> Studio if you don't have the latest version.
>
> There are a few other project files that are imported the same way:
>
> build\Dependencies.props - All of the NuGet PackageReference versions
> are here build\NuGet.props - NuGet properties common to most projects
> build\TestReferences.Common.props - NuGet PackageReferences that are
> shared between all test projects TestTargetFramework.proj - This is
> where you can set the TargetFramework to run tests on. Still looking
> for an alternative, see:
> https://stackoverflow.com/q/43554028
>
> Are you seeing the problem with those project imports as well? I don't
> mind changing it, it is just a matter of working out what change will
> fix the problem entirely. I was thinking about rolling the
> Version.proj settings into the root Directory.Build.props file anyway.
>
> Another possibility is that the Directory.Build.props file at the
> level of the project folders is missing from your system (not sure how
> that could happen, but maybe). The $(SolutionDir) MSBuild property is
> only valid when doing IDE builds. We patch it in a few of those files
> (they exist at a few different directory levels) so it will work
> whether in the IDE or command line. If you are missing the file, then
> the resolution of Version.proj could fail.
>
> Regards,
> Shad
>
>
>
> -----Original Message-----
> From: Chris Moschini <ch...@brass9.com>
> Sent: Sunday, July 14, 2019 8:48 PM
> To: dev@lucenenet.apache.org
> Subject: Version.proj
>
> The Lucene.Net projects added a dependency on an import:
>
> <Import Project="$(SolutionDir)Version.proj" />
>
> Sometime around the end of last year. Is there any documentation on
> what this Version.proj is supposed to be, or contain?
>
> We don't use such a proj in our Solutions, and pulling latest has
> caused all our builds to fail. Simply commenting out this line is a
> crude but effective way to prevent killing our builds here, but I have
> to suspect it's going to cause other problems by not having it...
>
Re: Version.proj
Posted by Chris Moschini <ch...@brass9.com>.
I'm using the latest version of Visual Studio 2019. I'm aware of the other
imports but as you note that don't cause any problems. The Version.proj
however breaks everything and the break is pretty bad. You basically have
to go in and edit csproj manually and remove it, which of course is going
to drag you away from upstream and make it hard for new potential devs to
contribute.
Is there any harm in getting rid of it?
Could we consider changing the extension to something like a .txt or
something so it doesn't freak out? Or some way to make it optional?
On Sun, Jul 14, 2019, 11:32 AM Shad Storhaug <sh...@shadstorhaug.com> wrote:
> Chris,
>
> Version.proj is a dependency of the build.ps1 build script, which was
> added before the last beta release in 2017. It is essentially the default
> version that will be used if you do a local build, and the major and minor
> version are parsed out of that file when certain parameters are used when
> doing a CI build.
>
> I noticed some weirdness when I was working on another project when trying
> to import a project file with a custom name in Visual Studio 2019, such as
> .proj. Apparently, Microsoft decided to lock it down so that the only valid
> extensions are .props and .targets (
> https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2019).
> However, when I opened Lucene.Net in Visual Studio 2019 a few weeks later
> it worked fine.
>
> I suspect that enough people complained that Microsoft updated Visual
> Studio to allow custom file extensions again. Try upgrading Visual Studio
> if you don't have the latest version.
>
> There are a few other project files that are imported the same way:
>
> build\Dependencies.props - All of the NuGet PackageReference versions are
> here
> build\NuGet.props - NuGet properties common to most projects
> build\TestReferences.Common.props - NuGet PackageReferences that are
> shared between all test projects
> TestTargetFramework.proj - This is where you can set the TargetFramework
> to run tests on. Still looking for an alternative, see:
> https://stackoverflow.com/q/43554028
>
> Are you seeing the problem with those project imports as well? I don't
> mind changing it, it is just a matter of working out what change will fix
> the problem entirely. I was thinking about rolling the Version.proj
> settings into the root Directory.Build.props file anyway.
>
> Another possibility is that the Directory.Build.props file at the level of
> the project folders is missing from your system (not sure how that could
> happen, but maybe). The $(SolutionDir) MSBuild property is only valid when
> doing IDE builds. We patch it in a few of those files (they exist at a few
> different directory levels) so it will work whether in the IDE or command
> line. If you are missing the file, then the resolution of Version.proj
> could fail.
>
> Regards,
> Shad
>
>
>
> -----Original Message-----
> From: Chris Moschini <ch...@brass9.com>
> Sent: Sunday, July 14, 2019 8:48 PM
> To: dev@lucenenet.apache.org
> Subject: Version.proj
>
> The Lucene.Net projects added a dependency on an import:
>
> <Import Project="$(SolutionDir)Version.proj" />
>
> Sometime around the end of last year. Is there any documentation on what
> this Version.proj is supposed to be, or contain?
>
> We don't use such a proj in our Solutions, and pulling latest has caused
> all our builds to fail. Simply commenting out this line is a crude but
> effective way to prevent killing our builds here, but I have to suspect
> it's going to cause other problems by not having it...
>
RE: Version.proj
Posted by Shad Storhaug <sh...@shadstorhaug.com>.
Chris,
Version.proj is a dependency of the build.ps1 build script, which was added before the last beta release in 2017. It is essentially the default version that will be used if you do a local build, and the major and minor version are parsed out of that file when certain parameters are used when doing a CI build.
I noticed some weirdness when I was working on another project when trying to import a project file with a custom name in Visual Studio 2019, such as .proj. Apparently, Microsoft decided to lock it down so that the only valid extensions are .props and .targets (https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2019). However, when I opened Lucene.Net in Visual Studio 2019 a few weeks later it worked fine.
I suspect that enough people complained that Microsoft updated Visual Studio to allow custom file extensions again. Try upgrading Visual Studio if you don't have the latest version.
There are a few other project files that are imported the same way:
build\Dependencies.props - All of the NuGet PackageReference versions are here
build\NuGet.props - NuGet properties common to most projects
build\TestReferences.Common.props - NuGet PackageReferences that are shared between all test projects
TestTargetFramework.proj - This is where you can set the TargetFramework to run tests on. Still looking for an alternative, see: https://stackoverflow.com/q/43554028
Are you seeing the problem with those project imports as well? I don't mind changing it, it is just a matter of working out what change will fix the problem entirely. I was thinking about rolling the Version.proj settings into the root Directory.Build.props file anyway.
Another possibility is that the Directory.Build.props file at the level of the project folders is missing from your system (not sure how that could happen, but maybe). The $(SolutionDir) MSBuild property is only valid when doing IDE builds. We patch it in a few of those files (they exist at a few different directory levels) so it will work whether in the IDE or command line. If you are missing the file, then the resolution of Version.proj could fail.
Regards,
Shad
-----Original Message-----
From: Chris Moschini <ch...@brass9.com>
Sent: Sunday, July 14, 2019 8:48 PM
To: dev@lucenenet.apache.org
Subject: Version.proj
The Lucene.Net projects added a dependency on an import:
<Import Project="$(SolutionDir)Version.proj" />
Sometime around the end of last year. Is there any documentation on what this Version.proj is supposed to be, or contain?
We don't use such a proj in our Solutions, and pulling latest has caused all our builds to fail. Simply commenting out this line is a crude but effective way to prevent killing our builds here, but I have to suspect it's going to cause other problems by not having it...
Version.proj
Posted by Chris Moschini <ch...@brass9.com>.
The Lucene.Net projects added a dependency on an import:
<Import Project="$(SolutionDir)Version.proj" />
Sometime around the end of last year. Is there any documentation on what
this Version.proj is supposed to be, or contain?
We don't use such a proj in our Solutions, and pulling latest has caused
all our builds to fail. Simply commenting out this line is a crude but
effective way to prevent killing our builds here, but I have to suspect
it's going to cause other problems by not having it...
RE: Build error on LuceneDocsPlugin: target "pack" does not exist
Posted by Shad Storhaug <sh...@shadstorhaug.com>.
Aaron,
The Lucene.Net.Tests project has ~3400 tests in it. What I am seeing on the command line is a fatal crash followed by a report with significantly fewer tests included in it. But it is inconsistent - sometimes it will fail after about 900 tests and other times it will fail after about 2900.
So far, I have gone back to the last release tag, pinned to the last known SDK that was used in global.json (which was 2.0.3), and found that the test run seems to complete there. It also completed with a newer SDK on that commit.
Going forward to the HEAD of master, the test run for .netcoreapp2.0 fails on the 2.0.3 SDK. I am still hunting for the commit that causes the difference, but there doesn't seem to be very many commits between those points that changed any code.
The failure is really obvious if you run them in Visual Studio 2017. The status bar at the bottom will indicate an unhandled exception, and if you check the Test Output you can see the message:
[7/9/2019 1:23:16 AM Error] The active Tests Run was aborted.
Unfortunately, there usually isn't anything helpful in there indicating which test caused the crash. Going forward, I am happy to see there is a --blame switch on the SDK which should help for this, but for the moment I am trying to rule out variables by sticking with the last known SDK that works.
Thanks,
Shad
-----Original Message-----
From: Aaron Meyers <Aa...@microsoft.com.INVALID>
Sent: Tuesday, July 9, 2019 1:54 AM
To: dev@lucenenet.apache.org
Subject: RE: Build error on LuceneDocsPlugin: target "pack" does not exist
Thanks all -- I worked around this by adding a dummy "pack" target to the LuceneDocsPlugin csproj which I inadvertently included in my PR for strong naming (will fix that).
I tried running the tests (using build -t) on Saturday and hit a lot of failed test cases across the set of projects. It does seem like the test run completed though as I got some test result XML files with passed and failed cases. So this seems to be a different result than what Shad is hitting below. I have .NET Core 3.0 preview installed as well as multiple .NET Core 2.x SDKs; I forced a 2.x SDK for Lucene.Net using the global.json file.
-----Original Message-----
From: Shad Storhaug <sh...@shadstorhaug.com>
Sent: Monday, July 8, 2019 3:40 AM
To: dev@lucenenet.apache.org
Subject: RE: Build error on LuceneDocsPlugin: target "pack" does not exist
Shannon,
I am working on a different approach for this by setting the IsPackable MSBuild property to false by default globally and using the solution file to do the pack rather than looping through each project file.
I would have pushed it already (along with some other fixes), but now the test runner is fatally crashing on .NET Core 2.x when testing Lucene.Net.dll. Still investigating.
Thanks,
Shad
-----Original Message-----
From: Shannon Deminick <sh...@umbraco.dk>
Sent: Monday, July 8, 2019 2:00 PM
To: dev@lucenenet.apache.org
Cc: Thomas Mathew <th...@microsoft.com>
Subject: Re: Build error on LuceneDocsPlugin: target "pack" does not exist
PR is here https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Flucenenet%2Fpull%2F228&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C2ae350ecacac4a468e6f08d70390b712%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636981792403944900&sdata=DdOLa%2FZ5ZyurrpLTo1jwVD1MSDbVuKOwRvLuw6J9k%2B8%3D&reserved=0
On Mon, Jul 8, 2019 at 4:51 PM Shannon Deminick <sh...@umbraco.dk> wrote:
> Found the issue, it's in the build.ps1 on line 199:
>
> $packages = Get-ChildItem -Path "$source_directory\**\*.csproj"
> -Recurse | ? {
>
> which is getting all csproj when it needs to ignore the
> LuceneDocsPlugins one. I'll send a PR for it soon.
>
> On Mon, Jul 8, 2019 at 4:40 PM Shannon Deminick <sh...@umbraco.dk>
> wrote:
>
>> Hi Aaron,
>>
>> I just ran the build.bat locally here and at the very end I get the
>> same error. TBH i don't think i've actually run this build file
>> before. This project is purely to build the documentation suite so
>> maybe its accidentally getting included in the main build script.
>> I'll see if i can find something obvious.
>>
>> Shannon
>>
>> On Sat, Jul 6, 2019 at 8:16 AM Aaron Meyers
>> <Aa...@microsoft.com.invalid> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to build the current Lucene.Net sources locally and I'm
>>> running into the following build error:
>>>
>>> C:\Data\github\lucenenet\src\docs\LuceneDocsPlugins\LuceneDocsPlugin
>>> s\LuceneDocsPlugins.csproj
>>> : error MSB4057: The targ
>>> et "pack" does not exist in the project.
>>> Error: 7/5/2019 3:00:22 PM:
>>> + ~~~~~& dotnet.exe pack $project --configuration
>>> $Configuration --output $nuget_package_directory --no -build
>>> --include.symbols /p:PackageVersion=$packageVersion
>>>
>>> I've poked around a little bit and haven't figured out what is going
>>> on
>>> - has anyone else run into this?
>>> My machine has multiple versions of VS (2015/2017/2019) and .NET
>>> Core SDKs (2.0 through 3.0 preview) so it might have something to do with that.
>>> It was trying to build using the 3.0 preview SDK which overrode with
>>> global.json in the lucenenet repo root but no effect on this build error.
>>>
>>> Thanks!
>>>
>>>
>>> Aaron Meyers
>>> Principal Software Engineer
>>> Microsoft Power BI
>>>
>>>
RE: Build error on LuceneDocsPlugin: target "pack" does not exist
Posted by Aaron Meyers <Aa...@microsoft.com.INVALID>.
Thanks all -- I worked around this by adding a dummy "pack" target to the LuceneDocsPlugin csproj which I inadvertently included in my PR for strong naming (will fix that).
I tried running the tests (using build -t) on Saturday and hit a lot of failed test cases across the set of projects. It does seem like the test run completed though as I got some test result XML files with passed and failed cases. So this seems to be a different result than what Shad is hitting below. I have .NET Core 3.0 preview installed as well as multiple .NET Core 2.x SDKs; I forced a 2.x SDK for Lucene.Net using the global.json file.
-----Original Message-----
From: Shad Storhaug <sh...@shadstorhaug.com>
Sent: Monday, July 8, 2019 3:40 AM
To: dev@lucenenet.apache.org
Subject: RE: Build error on LuceneDocsPlugin: target "pack" does not exist
Shannon,
I am working on a different approach for this by setting the IsPackable MSBuild property to false by default globally and using the solution file to do the pack rather than looping through each project file.
I would have pushed it already (along with some other fixes), but now the test runner is fatally crashing on .NET Core 2.x when testing Lucene.Net.dll. Still investigating.
Thanks,
Shad
-----Original Message-----
From: Shannon Deminick <sh...@umbraco.dk>
Sent: Monday, July 8, 2019 2:00 PM
To: dev@lucenenet.apache.org
Cc: Thomas Mathew <th...@microsoft.com>
Subject: Re: Build error on LuceneDocsPlugin: target "pack" does not exist
PR is here https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Flucenenet%2Fpull%2F228&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C2ae350ecacac4a468e6f08d70390b712%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636981792403944900&sdata=DdOLa%2FZ5ZyurrpLTo1jwVD1MSDbVuKOwRvLuw6J9k%2B8%3D&reserved=0
On Mon, Jul 8, 2019 at 4:51 PM Shannon Deminick <sh...@umbraco.dk> wrote:
> Found the issue, it's in the build.ps1 on line 199:
>
> $packages = Get-ChildItem -Path "$source_directory\**\*.csproj"
> -Recurse | ? {
>
> which is getting all csproj when it needs to ignore the
> LuceneDocsPlugins one. I'll send a PR for it soon.
>
> On Mon, Jul 8, 2019 at 4:40 PM Shannon Deminick <sh...@umbraco.dk>
> wrote:
>
>> Hi Aaron,
>>
>> I just ran the build.bat locally here and at the very end I get the
>> same error. TBH i don't think i've actually run this build file
>> before. This project is purely to build the documentation suite so
>> maybe its accidentally getting included in the main build script.
>> I'll see if i can find something obvious.
>>
>> Shannon
>>
>> On Sat, Jul 6, 2019 at 8:16 AM Aaron Meyers
>> <Aa...@microsoft.com.invalid> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to build the current Lucene.Net sources locally and I'm
>>> running into the following build error:
>>>
>>> C:\Data\github\lucenenet\src\docs\LuceneDocsPlugins\LuceneDocsPlugin
>>> s\LuceneDocsPlugins.csproj
>>> : error MSB4057: The targ
>>> et "pack" does not exist in the project.
>>> Error: 7/5/2019 3:00:22 PM:
>>> + ~~~~~& dotnet.exe pack $project --configuration
>>> $Configuration --output $nuget_package_directory --no -build
>>> --include.symbols /p:PackageVersion=$packageVersion
>>>
>>> I've poked around a little bit and haven't figured out what is going
>>> on
>>> - has anyone else run into this?
>>> My machine has multiple versions of VS (2015/2017/2019) and .NET
>>> Core SDKs (2.0 through 3.0 preview) so it might have something to do with that.
>>> It was trying to build using the 3.0 preview SDK which overrode with
>>> global.json in the lucenenet repo root but no effect on this build error.
>>>
>>> Thanks!
>>>
>>>
>>> Aaron Meyers
>>> Principal Software Engineer
>>> Microsoft Power BI
>>>
>>>
RE: Build error on LuceneDocsPlugin: target "pack" does not exist
Posted by Shad Storhaug <sh...@shadstorhaug.com>.
Shannon,
I am working on a different approach for this by setting the IsPackable MSBuild property to false by default globally and using the solution file to do the pack rather than looping through each project file.
I would have pushed it already (along with some other fixes), but now the test runner is fatally crashing on .NET Core 2.x when testing Lucene.Net.dll. Still investigating.
Thanks,
Shad
-----Original Message-----
From: Shannon Deminick <sh...@umbraco.dk>
Sent: Monday, July 8, 2019 2:00 PM
To: dev@lucenenet.apache.org
Cc: Thomas Mathew <th...@microsoft.com>
Subject: Re: Build error on LuceneDocsPlugin: target "pack" does not exist
PR is here https://github.com/apache/lucenenet/pull/228
On Mon, Jul 8, 2019 at 4:51 PM Shannon Deminick <sh...@umbraco.dk> wrote:
> Found the issue, it's in the build.ps1 on line 199:
>
> $packages = Get-ChildItem -Path "$source_directory\**\*.csproj"
> -Recurse | ? {
>
> which is getting all csproj when it needs to ignore the
> LuceneDocsPlugins one. I'll send a PR for it soon.
>
> On Mon, Jul 8, 2019 at 4:40 PM Shannon Deminick <sh...@umbraco.dk>
> wrote:
>
>> Hi Aaron,
>>
>> I just ran the build.bat locally here and at the very end I get the
>> same error. TBH i don't think i've actually run this build file
>> before. This project is purely to build the documentation suite so
>> maybe its accidentally getting included in the main build script.
>> I'll see if i can find something obvious.
>>
>> Shannon
>>
>> On Sat, Jul 6, 2019 at 8:16 AM Aaron Meyers
>> <Aa...@microsoft.com.invalid> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to build the current Lucene.Net sources locally and I'm
>>> running into the following build error:
>>>
>>> C:\Data\github\lucenenet\src\docs\LuceneDocsPlugins\LuceneDocsPlugin
>>> s\LuceneDocsPlugins.csproj
>>> : error MSB4057: The targ
>>> et "pack" does not exist in the project.
>>> Error: 7/5/2019 3:00:22 PM:
>>> + ~~~~~& dotnet.exe pack $project --configuration
>>> $Configuration --output $nuget_package_directory --no -build
>>> --include.symbols /p:PackageVersion=$packageVersion
>>>
>>> I've poked around a little bit and haven't figured out what is going
>>> on
>>> - has anyone else run into this?
>>> My machine has multiple versions of VS (2015/2017/2019) and .NET
>>> Core SDKs (2.0 through 3.0 preview) so it might have something to do with that.
>>> It was trying to build using the 3.0 preview SDK which overrode with
>>> global.json in the lucenenet repo root but no effect on this build error.
>>>
>>> Thanks!
>>>
>>>
>>> Aaron Meyers
>>> Principal Software Engineer
>>> Microsoft Power BI
>>>
>>>
Re: Build error on LuceneDocsPlugin: target "pack" does not exist
Posted by Shannon Deminick <sh...@umbraco.dk>.
PR is here https://github.com/apache/lucenenet/pull/228
On Mon, Jul 8, 2019 at 4:51 PM Shannon Deminick <sh...@umbraco.dk> wrote:
> Found the issue, it's in the build.ps1 on line 199:
>
> $packages = Get-ChildItem -Path "$source_directory\**\*.csproj" -Recurse |
> ? {
>
> which is getting all csproj when it needs to ignore the LuceneDocsPlugins
> one. I'll send a PR for it soon.
>
> On Mon, Jul 8, 2019 at 4:40 PM Shannon Deminick <sh...@umbraco.dk>
> wrote:
>
>> Hi Aaron,
>>
>> I just ran the build.bat locally here and at the very end I get the same
>> error. TBH i don't think i've actually run this build file before. This
>> project is purely to build the documentation suite so maybe its
>> accidentally getting included in the main build script. I'll see if i can
>> find something obvious.
>>
>> Shannon
>>
>> On Sat, Jul 6, 2019 at 8:16 AM Aaron Meyers
>> <Aa...@microsoft.com.invalid> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to build the current Lucene.Net sources locally and I'm
>>> running into the following build error:
>>>
>>> C:\Data\github\lucenenet\src\docs\LuceneDocsPlugins\LuceneDocsPlugins\LuceneDocsPlugins.csproj
>>> : error MSB4057: The targ
>>> et "pack" does not exist in the project.
>>> Error: 7/5/2019 3:00:22 PM:
>>> + ~~~~~& dotnet.exe pack $project --configuration
>>> $Configuration --output $nuget_package_directory --no
>>> -build --include.symbols /p:PackageVersion=$packageVersion
>>>
>>> I've poked around a little bit and haven't figured out what is going on
>>> - has anyone else run into this?
>>> My machine has multiple versions of VS (2015/2017/2019) and .NET Core
>>> SDKs (2.0 through 3.0 preview) so it might have something to do with that.
>>> It was trying to build using the 3.0 preview SDK which overrode with
>>> global.json in the lucenenet repo root but no effect on this build error.
>>>
>>> Thanks!
>>>
>>>
>>> Aaron Meyers
>>> Principal Software Engineer
>>> Microsoft Power BI
>>>
>>>
Re: Build error on LuceneDocsPlugin: target "pack" does not exist
Posted by Shannon Deminick <sh...@umbraco.dk>.
Found the issue, it's in the build.ps1 on line 199:
$packages = Get-ChildItem -Path "$source_directory\**\*.csproj" -Recurse |
? {
which is getting all csproj when it needs to ignore the LuceneDocsPlugins
one. I'll send a PR for it soon.
On Mon, Jul 8, 2019 at 4:40 PM Shannon Deminick <sh...@umbraco.dk> wrote:
> Hi Aaron,
>
> I just ran the build.bat locally here and at the very end I get the same
> error. TBH i don't think i've actually run this build file before. This
> project is purely to build the documentation suite so maybe its
> accidentally getting included in the main build script. I'll see if i can
> find something obvious.
>
> Shannon
>
> On Sat, Jul 6, 2019 at 8:16 AM Aaron Meyers
> <Aa...@microsoft.com.invalid> wrote:
>
>> Hi all,
>>
>> I'm trying to build the current Lucene.Net sources locally and I'm
>> running into the following build error:
>>
>> C:\Data\github\lucenenet\src\docs\LuceneDocsPlugins\LuceneDocsPlugins\LuceneDocsPlugins.csproj
>> : error MSB4057: The targ
>> et "pack" does not exist in the project.
>> Error: 7/5/2019 3:00:22 PM:
>> + ~~~~~& dotnet.exe pack $project --configuration
>> $Configuration --output $nuget_package_directory --no
>> -build --include.symbols /p:PackageVersion=$packageVersion
>>
>> I've poked around a little bit and haven't figured out what is going on -
>> has anyone else run into this?
>> My machine has multiple versions of VS (2015/2017/2019) and .NET Core
>> SDKs (2.0 through 3.0 preview) so it might have something to do with that.
>> It was trying to build using the 3.0 preview SDK which overrode with
>> global.json in the lucenenet repo root but no effect on this build error.
>>
>> Thanks!
>>
>>
>> Aaron Meyers
>> Principal Software Engineer
>> Microsoft Power BI
>>
>>
Re: Build error on LuceneDocsPlugin: target "pack" does not exist
Posted by Shannon Deminick <sh...@umbraco.dk>.
Hi Aaron,
I just ran the build.bat locally here and at the very end I get the same
error. TBH i don't think i've actually run this build file before. This
project is purely to build the documentation suite so maybe its
accidentally getting included in the main build script. I'll see if i can
find something obvious.
Shannon
On Sat, Jul 6, 2019 at 8:16 AM Aaron Meyers
<Aa...@microsoft.com.invalid> wrote:
> Hi all,
>
> I'm trying to build the current Lucene.Net sources locally and I'm running
> into the following build error:
>
> C:\Data\github\lucenenet\src\docs\LuceneDocsPlugins\LuceneDocsPlugins\LuceneDocsPlugins.csproj
> : error MSB4057: The targ
> et "pack" does not exist in the project.
> Error: 7/5/2019 3:00:22 PM:
> + ~~~~~& dotnet.exe pack $project --configuration
> $Configuration --output $nuget_package_directory --no
> -build --include.symbols /p:PackageVersion=$packageVersion
>
> I've poked around a little bit and haven't figured out what is going on -
> has anyone else run into this?
> My machine has multiple versions of VS (2015/2017/2019) and .NET Core SDKs
> (2.0 through 3.0 preview) so it might have something to do with that. It
> was trying to build using the 3.0 preview SDK which overrode with
> global.json in the lucenenet repo root but no effect on this build error.
>
> Thanks!
>
>
> Aaron Meyers
> Principal Software Engineer
> Microsoft Power BI
>
>