lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Moschini <ch...@brass9.com>
Subject Re: Version.proj
Date Sun, 14 Jul 2019 15:59:09 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message