Creating sqlhydra file updates the wrong .fsproj file

[Janna112358]

Issue

I work with several F# solutions that have a file structure along the lines of:

.
├── README.md
├── Build.fsproj
├── ...
├── server
│   ├── server.fsproj
│   ├── ...
│   └── Common
│      └── Db.fs
├── tests
│   ├── tests.fsproj
│   └──...

I use sqlhydra to generate the file at ./server/Common/Db.fs, and write instructions in the README for other developers to do the same (after schema changes) from the repo root. I've noticed that sqlhyra automatically adds en entry for the generated file in the Build.fsproj. However, I need the file to be compiled as part of the server project. (Moving the entry to server.fsproj is a one-time thing; sqlhydra changing Build.fsproj on every use is the main thing I would like to be able to change.)

Ideas

I would love to be able to pass a --project /path/to/project.fsproj argument to the client tool, or store the target project as a configuration in the .toml file. Alternatively, an option to simply turn off the tool updating any .fsproj file would also help a lot.

[JordanMarr]

That sounds like a good addition.

[JordanMarr]

v2.3.1 has been published. Adds new option as -p or --project.

[Janna112358]

Thank you, amazing! I'm using it right away :)

[Janna112358]

Sorry to reopen, but I'm noticing that the Compiler entry that is created doesn't get the path quite right. With the file structure from the example, the tool adds

    <Compile Include="server/Common/Db.fs">
      <Visible>False</Visible>
    </Compile>

but since the .fsproj file is withing the server directory, I need it to be

    <Compile Include="Common/Db.fs">
      <Visible>False</Visible>
    </Compile>

I'm happy to have a go at fixing this myself, maybe?

[JordanMarr]

If you are feeling ambitious, you are certainly welcome to submit a PR. If not, I don't mind doing it.

There is a "devcontainer" setup that is supposed to magically spin up a vs code environment, but TBH, I've had issues with it recently. I think it may need to TLC to get it working. So, I would recommend just manually spinning up the docker containers using docker-compose up.

[Janna112358]

Alright, I'm indeed running into trouble with the docker container (with the devcontainer extension and with the manual command) and I don't really have the know-how to try and fix that. So I will pass it back to you!

[JordanMarr]

Here is my understanding of your issue:

• Normally, the cli tool generates the output file in the run directory, and assumes the fsproj file is also in that directory.
• You are running the cli tool from a different director than the target project, so your generated file is created in the run directory, and the --project setting updates the fsproj file with the current directory path.

And what should happen:

• The generated file should instead be created in the project folder (per the configured --project), so that the project entry is correct.

[JordanMarr]

SqlHydra.Cli v2.3.2 is published:

• The generated file is now created relative to the specified project file.

[Janna112358]

Great! I've tested 2.3.2 and indeed what I do is:

• I run the cli from the root of the repository, with option --project path/to/targetProject.fsproj
• Instead of giving the absolute path for the sqlhydra output file, I now give it a path relative to the targetProject.fsproj
• Now the output file is put in the targetProject AND the compiler entry in targetProject.fsproj uses the relative path as expected :)

I've checked it with and without the output file and/or the compiler entry in targetProject.fsproj already existing, and all good!

Thanks very much for this, it makes my life just a little bit easier 🙏