[Suggestion] Support for multiple projects with deliverable output #101
Conversation
Allows for multiple projects in the src folder, each can be released as a nuget package Nuget packaging now automatically infers dependencies based on paket settings.
|
Currently I'm trying to document the current status of the project - see 2014-10-16 15:35 GMT+02:00 Vidar Løvbrekke Sømme [email protected]:
|
|
I currently have a forked branch that works with single project C# libraries (dll deliverables) planning to look into mixed solutions soon 😄 |
|
woah curly braces. Joking aside the goal is to make this also the goto place for C# only projects. |
|
Trying to encourage my team to use whatever tool is best, (particularly to experiment with F#) so having a low barrier for mixed solutions is important. (And not a lot is required to support it, it was easy to support C# only, I just haven't done the mixed part yet.) |
|
yes what I mean is: we want the C# community to use this (and improve it for their needs). |
|
It would seem I have a case of it works on my machine. @forki Can you have a look at the log and see if you can bring some light on what I am doing wrong? (not allowed to access the default bin folders it seems) |
|
mhm looks like it's not a relative path |
|
should probably have a leading . then. |
* For dependencies between projects in the same solution, a nuget dependency to the generated package for the projects are added to the nuspec * For projects with Exe output type, All files in the relevant bin folder are added to the nuget package, no dependencies. Cause dealing with dependencies in a deploy situation is not really fun.
|
I know you are putting a lot of effort into docs now @forki , but this is stuff we're going to use internally anyway, and I'd like to share it in case any of it is interesting for the community. Following are added: Inter project dependenciesIf any library type project have dependencies (project references) to other library projects in the same solution, the dll's are not included in generated nuget package, but a dependency is added to the nuspec. Example: Simple.Data by Mark Rendle (https://github.com/markrendle/Simple.Data) have a core lib and multiple providers and adapters that have different interdependencies. Each of those are published as separate packages with nuget dependencies declared on each other. Executable projectsWhen packing an application type project as a nuget it is usually for some sort of automated deploy. In my opinion, dependencies should be resolved at packaging stage (when you have some sort of oversight) and not at deploy time. The strategy for creating nuget packages when project output type is set to Exe is therefor different than for Libraries. For Exe type projects, all files in the bin folder are added to the nuget package, and no dependencies are added to the nuspec. Concerns
|
|
I can assure you @agross and I are working on a solution to this. :-) It's cool to see people are interested.
|
|
Good to hear, let me know if I can help out |
|
Yes we will probably need people who are willing to test alpha versions and
|
|
Do you have any idea of when you will get to these parts? (I hate getting these questions myself, sorry) But If it is in the near future, like a couple of weeks, I'd rather spend some time helping out getting a nice open source version going, than hacking on my own private fork (that I then have to maintain myself). |
|
Also, that build failed for some weird reason before it even got to testing the actual code. |
|
We will discuss the strategy this weekend. I will then log some issues into Actually I think a basic version should not be too hard. We have most of
|
Changed how libdirs are resolved for generating API docs with the new bin folder hierarchy.
|
ccing @agross I think we are ready to start this. |
| // Copies binaries from default VS location to exepcted bin folder | ||
| // But keeps a subdirectory structure for each project in the | ||
| // src folder to support multiple project outputs | ||
| Target "CopyBinaries" (fun _ -> |
There was a problem hiding this comment.
why is this step needed? I assume only for the test step, right? why not change the search pattern there?
There was a problem hiding this comment.
Two reasons:
- You can add new projects without changing default settings.
- Even with the default settings, I like to have my binaries in one place after build
But this is all just for convenience based on peronal preferences, more than actual requirements.
Big thing is not to have all bins for all projects in a single messy bin folder with no proj structure
There was a problem hiding this comment.
we are building opnionated solution layout so opions are good.
|
Thanks @forki. Works as a charm 😄 (Also, adding the scaffolding project as another remote, and merging, works really great. Thanks for the tip.) |
| | Minimum(semver) when (semver.ToString()) = "0" -> Minimum(getCurrentlyInstalledVersion p.Name resolved) | ||
| | version -> version | ||
|
|
||
| let getReferencedPackagesFromProject projectRefFile = |
There was a problem hiding this comment.
did you see fsprojects/Paket@75e8896#diff-1c0402362ea00603323e9471b28eba0eR178?
Is that what you need?
There was a problem hiding this comment.
Partly, it gets me the names. But I also need any version restriction from paket.dependencies
There was a problem hiding this comment.
Also, just reading the reference file directly is actually less code than using GetPackageHull (as I do not require indirect dependencies)
There was a problem hiding this comment.
Yes you are right that was the wrong one.
Please try fsprojects/Paket@667a1e6#diff-99b45a5cb27d99b9474be5250b7d8f99R16
|
Tried to simplify a bit now and found that:
Just had time for a quick look tonight, will continue tomorrow I hope. |
|
I think we came to the point where the discussions is hard to follow. |
|
Also we now have fsprojects/Paket@9ea7028#diff-bb5be43f98d6a2cbf84418f550d07b97R309 |
|
Thanks for all the good help, closing this while integrating all the new Paket goodness 😄 |
Sometimes it is reasonable to collect multiple projects that creates separate deliverables in the same solution.
For our case the concrete use case is feature verticals. I.E We try to do narrow verticals with both server side, client side (and some times other stuff) together. Some UI projects will then depend on several of the Client packages from these vertical projects in order to function.
Currently the scaffolding project focuses on single project libraries. This suggestion implements support for multiple projects with separate deliverables.
Overview of changes:
These changes should not be breaking for single project libraries (biggest change is one extra folder layer in bin folder), but it enables basic multi project.
Todo
This is just an initial suggestion, mainly to get some feedback on whether I'm way off scope (and should keep this stuff in my own fork) or not. So some stuff is still pending, and some changes may need to be made.
If a project references another project in the solution. (IE the UI project references the messaging project) you don't want to have to deal with nuget during dev, but when some other project references the UI project, it should have a dependency on the messaging deliverable.