lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shad Storhaug <s...@shadstorhaug.com>
Subject RE: Version.proj
Date Mon, 15 Jul 2019 10:25:31 GMT
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 <shad@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 <chris@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 <shad@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 <chris@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...
>
Mime
View raw message