Add Multi repo support #1137
Replies: 55 comments 71 replies
|
Clone multiple repos locally, create an Uber solution and add the apphost to it, wiring up all of the projects required. That's where I would start. it you don’t want to pull and run the other repos locally, then I’m not sure exactly what the workflow would be (point to something already running). |
|
Can someone explain what is the Uber solution? |
|
Mohammad Helal (@massina) A big solution that contains all these cloned projects. Hence "uber". |
|
David Fowler (@davidfowl) - Spending lots of time thinking about what you're saying about the ubersolution. I'm going to try it out with my tinkering locally as a vessel to learn dapr. I think it makes sense...
I feel like there's a little bit of opportunity for some Aspire magic to smooth things over in the ubersolutions? |
Could Aspire do something like this? |
I am doing this for the last 2 years, it is working very well. everything working fine. some projects has about 6 repos like this. to easy the clone I always create a .bat the has all the repos I am required to clone. next step is to setup azd pipeline config, I haven't done that yet. but chatGpt gave a pratical solution, just add repositories to the created yaml and then clone in the step of deploy. |
|
Some patterns I imagine might emerge:
|
|
I believe we would need to publish our service defaults as a NuGet package, published to our own private NuGet server (Azure Artifacts in our case). Then projects throughout all the different repos could add a reference to this service defaults NuGet package. |
|
using NuGet might complicate debugging and hinder quick updates. |
|
Although this is true, how often would you realistically want to change/debug the service defaults? And when you do - when we want to debug the code delivered via nuget package, we just take a local clone of the repo and swap the nuget reference out for a project reference in the solution so it's fairly simple to get a local setup ready for debugging. So it is a complication, but a small one and the benefit of sharing the defaults via nuget outweighs it. |
|
Always dreamed of having a primitive that would look something like <ProjectReference Include="../Foo/Foo.csproj">
<FallbackPackageReference Include="Foo" Version="1.0.0" />
</ProjectReference>Although, I do also think it would make things much harder to have a mental model of what's going on, have good build reproducibility. Maybe something like this: <PackageReference Include="Foo" Version="1.0.0" ProjectReference="../Foo/Foo.csproj" />And a parameter like With that said, having the service defaults as a project reference for smaller codebases makes sense, but I feel it doesn't grow well into a large system of composed services. Also, you may not want to push a fundamental service default change across the whole system at once since those changes tend to have impact. The solution of moving it to a NuGet enables the gradual rollout of those changes across a system while re-using knowledge, behaviors and expectations of devs towards NuGet upgrades in their system. |
|
Yeah, I'd want the project reference to be supplementary to a more reliable package reference. That way if the project doesn't exist, no problem. But I don't think Microsoft has taken the reality of multiple solutions seriously enough yet. |
Yep, or you could put the ServiceDefaults in a sub-module and include it that way. There are lots of ways for folks to share code and assets among teams and I don't think we want to be too prescriptive about it. We should ensure we're flexible enough to support different patterns. |
|
Damian Edwards (@DamianEdwards) would be nice to have some samples on how to proceed with multi-repo scenarios. It is definitely a very cool and useful tool, but a huge part of microservice solutions are split across different repos, and in this case its not that obvious how to utilize it in local environment. |
|
I also don't understand how the deployment story is in this scenario, where we "run" our k8s cluster with a custom cloud platform team. For instance, we use github + tekton pipelines + argo CD to deploy to k8s using multiple repos (one per service), all things k8s related are generated/managed by the platform (I've worked in previous companies with similar setup bu using different tools like gitlab as an example) How Aspire can be helpful in this cases? |
Are you cloning everyone's repositories and running them today? |
It sounds like you don't need to use the deployment part of aspire because you have already figured it out! It's still great for local development, using components, and service discovery! |
|
David Fowler (@davidfowl) Yes, we clone all the repositories locally and debug service communication having multiple studio instances opened. Its doable, but its a pain. |
|
Artyom (@artyom-p) What does the pain free solution look like? What would you ideal experience be? |
|
David Fowler (@davidfowl) Let's say we have 2 microservices that need to communicate with each other, they live in their own git repositories. Each microservice can have its own or shared dependencies, for example: There are cases when you want to debug only one service, but you still need another one to be running with all its dependencies, in this case, we can just somehow reference that second service and make it run, I think there was something similar in Tye before if I'm not mistaken. The second case is more complex - when you want to debug both services. I'm not sure if it's doable without referencing projects of ServiceB in ServiceA solution. |
|
We also have the same multi-repo approach here, and this is where Tye was really strong for local development. A tye.yaml file could be relatively pathed to target x services, all cloned locally. Tye was also useable as a completely external tool, no changes were required to any service, and they could also target a variety of different dotnet versions. Aspire looks so much better in many ways to Tye, and I can see it's trying to achieve different things, but being able to use Tye as a non-invasive external local dev orchestrator remains a huge benefit and time saver for multi-repo scenarios. |
You can do a similar thing with the app host. Clone multiple repositories and create a project file that references individual projects. Maybe we need to enable referencing app hosts themselves 🤔.
Aspire does require .NET 8 and above.
Can you show me your tye setup? |
That could be a solution! In our case, we have git repositories per service in a system. We expect to do the following:
I have the impression we could generate a strongly typed dll/nuget that would expose another app host's resources which would enable us to have compile time errors. This would come with a challenge for handling circular dependencies, generated constants representing the resources from another app host could be enough. I'd love to be able to use Aspire here. We have a few hundreds of services, thinking about having them all cloned with the right version is not practical. I'd rather have Renovate / Dependabot update nuget refrences and have build pipelines validate the integrity of the system. |
|
What are you trying to accomplish though? Is the goal to run with another team's dependencies? |
|
The end goal is running services with their dependencies in production for sure! With that said, when services are ran locally, they either have mocks for dependencies or they act a one of the services within an actual deployment (far from ideal since you can get traffic from other people on that system). One of the reason to interconnect the services from different repositories/teams is to have a build time check that all interconnections between the service are valid, ie: Foo service that required Bar service's url should fail at build time if the Bar service has not been declared in the system. In a distributed system, it would also enable having a shared redis cache deployment while keeping the ownership of that part outside of the team's boundary (for example, a platform engineering team could expose their resources and service teams could consume those in a safe way, not just a magic configuration key that comes from who knows where). |
|
Many thanks for the reply, really enjoying the Conf this year.
You say that, and of course you're totally correct if you want to use everything in the Aspire stack (and who am I to argue with the mad professors who came up with this amazing stuff), but I have been able to hack something together today from the starter application template using AddExecutable(): In this case, ApiService6 is a dotnet6 api, inside which I've added OpenTelemetry support based on the code in the ServiceDefaults project. You do then end up with traces and (partial) metrics in the Asipre dashboard. So this is potentially useful-ish (I should try this with func.exe as well to see if we can spin up Functions in a decent way while Function support isn't quite ready yet). Service discovery is obvs broken here, and Aspire Components are presumably off the table too. This serves two purposes though - allows some use of older dotnet applications, and also allows targeting of different repos outside of the solution the Aspire AppHost lives in. So it falls back to a similar kind of experience to Tye in these respects.
Sure, we have a lot of tye files, each targeting a specific surface area of our microservices (which are all in individual repos). Redacted example below: Key thing here is that we haven't made any code changes to any of these services, and they're spread over 4 different repos. |
|
Artyom (@artyom-p) I've opened microsoft/aspire-samples#35 to track adding some samples of multi-repo orchestration from an AppHost project. |
|
Love it. Something like Although I agree it has an out-of-scopey flavour, I could see it being a very popular feature or extension. We'll see 🙂 |
|
So what if I had multiple projects within the same git repository? Would it know to not try and re-clone it? |
|
You can set a different clone target path. Than you can have 1 repo 2 different project states |
|
Hmm, not sure I follow. I'm just saying, if I have two "entrypoints" in a single repository, can that be supported without having to clone the repo multiple times? |
|
I have updated again because in our workflow this works better, and maybe the documentation is better now too? |
|
I'm encountering some resistance at my workplace when I sugggested trying out Aspire. This seems like it could be an easy way for me and other curious devs to try it out without disturbing the workflow for the old schoolers that just want to work in the specific repo? |
|
Hey, I've been working on a project that I think may be useful for some here. Please feel free to send feedback and let me know what you think. |
|
So... after a few months, no further progress on multi-repo support? Is it already implemented? |
|
There's a pretty cool implementation #1137 (reply in thread), that you can try out. |
|
I'm working on this at the moment, so it is still in flux. But if anyone wants to look at it and suggest any features that I missed that would be amazing :). |
|
thanks for the awesome answers! |
|
Not directly a multi-repo problem, but I have multiple solutions in the same repo. To reference an "external" project in the repo, I tried to use: |
|
Experiencing same issue here. Did you manage to resolve the issue? Jørn H. Dalvik (@jornhd) |
|
Unfortunately no. I've tried debugging it, and it does actually find and read the launchSettings.json file, but I still get this error. Could be a bug in Aspire. |
|
FYI, i just got it working using CLI rather than visual studio. Possibly a visual studio issue? |
|
Hello, Currently, our team uses a microservice architecture where each microservice resides in its own repository and is maintained by a dedicated team. We also use Docker Compose for each microservice to manage running the API, database, Redis, RabbitMQ, etc. Most of the time, each team deals only with their own microservice, but occasionally, they run all the microservices locally for end-to-end testing. To facilitate this, we have created another Docker Compose file that runs all the microservices along with their dependencies. Now, my question is: if we decide to go with Aspire, the use case where we want to run all the microservices locally works fine using one Uber AppHost solution and sharing ServiceDefaults as a NuGet package. But how would you suggest we run individual microservices (that currently use Docker Compose)? Besides the Uber AppHost, should we also have an AppHost per microservice that stays in the same repository as the microservice? Or is there another solution anyone would suggest? Thanks. |
|
Are you planning to always run the microservices from other repos using container images that have been published, or would you be getting the source code and running them as regular projects? Either way, you could use separate AppHost projects with each only configuring the resources you want, or you could use one AppHost project with separate launch profiles (configured in |
|
Damian Edwards (@DamianEdwards) Thanks for your response... Currently, we are getting the source code of each microservice and running them using Docker Compose. This is how we plan to proceed going forward. However, most of the time, each team is only working on their own microservice. Based on your suggestion, I believe I have two options:
I am leaning more towards Option 1, as we already have Docker Compose for each microservice. Additionally, I think it would be easier for each team to just clone their microservice and work with it using its own AppHost. |
|
Just to add to the multi-repo thing (using an Uber solution), being able to control provisioned resource name in Aspire 9 goes a long way (if not all the way for me) towards making Aspire work well with multiple repos and single/centralized resources. While it's not baked in connecting to another repo and spinning it up as a container as some will be after, if you're happy just adding projects from other solutions where required (vs 2022 does a good job with multi-repo solutions) and having an Uber solution for deployment, with fixed resource names you can:
More detail here: #6484 |
|
I have five microservices in different Azure repositories. I created a new repository for the Aspire solution. After that, I added the projects to the Aspire solution, and everything worked very well. The deployment to Azure App Container also worked using azd init and azd up. However, I encountered a problem: in the Azure pipeline, I can't figure out how to replicate this process. ProjectFolder |
|
So a tradeoff was made to use separate repos for different reasons (permissions etc) but it’s really a single monolithic project. Is that right? |
|
I don't think so. |
|
If they are independent, why do devs need to clone it all to run it? |
|
I think they don't need to. but sometimes prefer to. maybe easier to debug some specific task involve communication between micro services, or to see the big picture, or some other reason. |
|
We also use a similar setup at our team. Multiple repos, most dotnet, but also some Python backend projects and a react frontend. One repo per service. All services are developed independent from each other, but some of the services have soft dependencies on others, so you often need to run most of them to actually test stuff. I will try a setup similar to omar's. It would be really nice to be able to start all services from the AppHost, then open a spesific project in another VS instance and be able to do stuff like attach debugger. |
|
Edit: One of my goals was to explicitly avoid bringing in the other projects as real projects. In our case, we don't want all that metadata bogging down the IDE. What I'm considering for cross-repo debugging is having the AppHost in the "Stack" repo optionally point at host endpoints, and then the user can open multiple IDEs as they see fit. This is what I am doing, though how much Aspire could further help is questionable - but maybe could inspire something builtin? "Stack" RepoThis repo contains two projects: Stack and AppHost. AppHost is a bare-bones host that contains a non-Aspire reference to Stack, which contains basically everything else. <ItemGroup>
<ProjectReference Include="..\Stack\Stack.csproj" IsAspireProjectResource="false"/>
</ItemGroup>The second project has its own builder private IResourceBuilder<IResource>? _myProject1;
private IResourceBuilder<IResource>? _myProject2;
public StackBuilder WithMyProject1<T>(
Action<IResourceBuilder<AzureFunctionsProjectResource>>? configure = null)
where T : IProjectMetadata, new()
{
var res = _dab.AddAzureFunctionsProject<T>();
configure?.Invoke(res);
_myProject1 = res;
}
public StackBuilder WithMyProject2<T>(
Action<IResourceBuilder<ProjectResource>>? configure = null)
where T : IProjectMetadata, new()
{
var res = _dab.AddProject<T>();
configure?.Invoke(res);
_myProject2 = res;
}
// etc.The stack builder will do the following for each project: if (_myProject1 == null) {
// Consider allowing the tag to be configurable, so that e.g. containers from PRs can be used
_myProject1 = _dab.AddContainer(/* ... */);
}
if (_myProject2 == null) {
_myProject2 = _dab.AddContainer(/* ... */);
}
ApplyMyProject1Config(_myProject1);
ApplyMyProject1Config(_myProject2);This is where we could see some improvements to the API. You'll notice that the fields are _myProject1.AsResource<IResourceWithEnvironment>().Inspect(v => v.WithEnvironment(/* ... */))At this point the stack repo should be capable of bringing up any combination of the repos, where each is either the real project or a container. The The "MyProject1" Repo (i.e. each micro repo)This repo has its own var stack = new StackBuilder(args);
stack.WithMyProject1<Projects.MyProject1>();
stack.Build().Run();Thereby disabling the container and using the real project. This repo also has to publish "MyProject1" as a container image, so that the |
|
Are you planning to open source this? |
|
David Fowler (@davidfowl) it would be a struggle purely in terms of figuring out what that would look like. This is almost entirely a pattern. I'll give some thought about an API that could guide people through developing the pattern - probably something like an |
Jonathan Dickinson (@jcdickinson) a sample setup would be appreciated here. |
|
I have since decided that I will not be contributing to this project in any way because it is not completely open source, and in solidarity for the recent 3% laid off. |
|
Same multi-repo requirement here. We have some scenarios where I would like to run 5-6 micro-services locally (coordinated with Aspire) and I want to be able to attach a debugger to one or more of these services during the execution. So I created a simple solution containing a single project with the AppHost. The AppHost would call a AddProject(path_to_external_service_project) for each service. This works well, but I cannot attach a debugger to one of my service because Aspire is already attached to my services. Is there a way to avoid this? I tried running Aspire outside of a debugger (dotnet run --project AsppHost.pcsproj), but got the same behavior. This link seems to imply that this is not yet implemented? AppHost configuration to not attach debugger to a project #4761 |
|
I just re-ran Aspire though CLI (dotnet run --project AsppHost.pcsproj) and I was able to attach. Bad manipulation on my part sorry :( For your question David Fowler (@davidfowl),
Currently Aspire helps us starts a service locally with all its direct dependencies. But my goal would be able to start all the services required for a certain flow locally (either using directly the project path like in my example or using docker image depending on the cases). Being multi-repo is the challenge here. |
|
I am still fairly new to Aspire, but my understanding is that we use an AppHost to describe the full setup of an environment, which works well for centralized configuration. However, I’ve found myself wishing for a more modular approach—specifically, a way for each service to declare its own direct dependencies (e.g., a cache, Cosmos DB, etc.) in a self-contained manner. Beyond that, I’d love to be able to describe how services interact with each other and define inter-service dependencies more explicitly (in a different AppHost). This would help us better model the architecture as a graph of services and resources, rather than a flat list defined in a single host. Is that something possible currently? |
|
Sure, the set of resource is a graph (there's even a graph view!). I think about this like producing hosting integrations for each microservice and then consuming it in another one. We don't have any first-class support for turning an apphost or a subset of an apphost into a nuget package + container image combo that can be consumed, but I think that would make it easier to author and consume these depedendencies. If you do truly need the source of your dependency though, then there's no alternative but to clone their repo and add their project(s) and dependencies to your app host. Lots of things are possible, this project was built outside of the core of aspire (it can be extended to support many things). The team is still unclear on exactly what to build here, there may be multiple things.. Here's a deeper dive on the model https://gist.github.com/davidfowl/b408af870d4b5b54a28bf18bffa127e1 I also recommend watching some of the aspirifridays as we show how to model existing apps: https://www.youtube.com/playlist?list=PLSi5JsxQ5oNsxyJk2HRBI35S0862vElfg |
Instead the path, add all the projects to the aspire solution. then addproject reference.
|
|
Hey David Fowler (@davidfowl), Just wanted to chime in and express our teams desire for similar multi-repo support,
We'd love to use Aspire instead of a compose solution so we can have everything in one dashboard, it'd make debugging our cross-microservice layer so much easier in addition to metrics, logs, and traces. https://github.com/Dutchskull/Aspire.PolyRepo is a solution to at least run our services all together with minimal effort, however we lose out on the ability to quickly re-start a service to test changes or attach a debugger. The only remaining option that I'm aware of is to create a gigantic uber-solution that.. frankly would likely break our Visual Studio or Rider IDE's, as we'd have nearly ~50-80 projects all in a singular solution. Our docker-compose setup makes use of a shared docker-compose project & network,
To visualize this, This compose is spun up using a remote image, name: stack
services:
fake-microservice:
image: mcr.microsoft.com/dotnet/aspire-dashboard:8.1
container_name: fake-microservice
ports:
- 18888:18888
networks:
default:
external: true
name: stack-wide-networkWhen this compose is spun up it replaces the remote-image defined container in-place, usually it's spun up by an IDE using a .dcproj name: stack
services:
fake-microservice:
image: fake-microservice:local
container_name: fake-microservice
build:
dockerfile: Dockerfile
ports:
- 18888:18888
networks:
default:
external: true
name: stack-wide-networkI'm sure it's just a dream, but giving Aspire a similar ability to swap out individual services/resources from other Aspire hosts or sub-hosts of some kind could be a potential multi-repo solution. Essentially it'd be a host that lives inside each microservices solution that can optionally signal to an existing aspire host, labeled by a name, port, or endpoint, that X resource should be swapped out with X ResourceBuilder definition. |
|
With Aspire now supporting multi‑language scenarios, multi‑repo support has become even more valuable for us. In our enterprise environment, services are distributed across multiple repositories, managed by different teams, and implemented in various languages (.NET, NodeJS, Java). To deploy a complete solution (whether locally, on‑premises, or on Azure) we need to connect all these services, and Aspire’s multi‑repo orchestration would make that possible, even for local development. Is multi‑repo support already planned on the mid/short‑term roadmap? |
|
Hard to say. It's on the roadmap, but it's not short term, maybe mid term. |
|
In Aspire 13, I see a new feature Automatic Dockerfile generation, that seems to be one cool feature possibly leveraged to make it easier for multi-repo support. That's currently for Python, but if that extend for all supported language then I could imagine that multi-repo/multi-language could be supported with container resource as part of aspire integration in each repo. |
|
Chuanbo Zhang (@chuanboz) it's really easy to use so yes this could be a key piece of the producer side of things. We're currently resolving the build tag and push to registry step. To make integrations work there's an additional piece but the pipeline is a great building block. |
|
David Fowler (@davidfowl) , great to hear that align with the multi-repo producer side direction. Yes, pipeline is another great addition in Aspire 13, that not only help deployment, but also could be leveraged for publish. I also see Aspire Publisher model and Callback valuable to allow customize for multi-repo container support. For out-of-box native experience, I would imagine following simple experience would be great:
|
|
David Fowler (@davidfowl) Now that Aspire supports a polyglot AppHost (C# + TypeScript), we may consider adopting frontend mono‑repos (using NX) to define the frontend portion of the AppHost responsible for our Apps orchestration, to be deployed alongside our .NET micro service APIs. |
|
See https://devblogs.microsoft.com/aspire/aspire-windows-365/ for windows 365 integration of multi-repo support based on existing aspire primitive with container resources as microservice resource abstraction |
|
YohanS (@YohanSciubukgian) , how do you think of experience shared here, will that work for your enterprise scenario? |
|
Chuanbo Zhang (@chuanboz) Thanks for sharing the blog! It’s exciting to see Aspire being extended in this way, paving the path for future core features. |
|
YohanS (@YohanSciubukgian) , I’m really glad to hear you enjoyed the experience we’ve created. I’d be happy to answer any detailed questions you may have about how we implemented each part of the story. As for making a public repo that’s reusable for everyone, that would require additional effort and ongoing support, so we would need more discussion and asks before we could commit on that. |
|
Hi Chuanbo Zhang (@chuanboz), thanks for the blog, this is really exciting! I’m very interested in the demo project + the supporting packages/logic, especially around Service Discovery and the microservice/Azure dependency emulator logic and how they’re modeled + wired into Aspire. I totally get that making this public is extra work, but I’d really appreciate it since this is clearly a pain point many people hit, and I think a reference implementation would significantly boost Aspire adoption in enterprises. |
|
Glad you like the experience, we could help Aspire team to make sure they they eventually build would meet the people's needs. for Service Discovery, as we have shared infra team, so we control the client library, and so baked the service discovery via environment variables and service map into the client library or just leverage native .net client library with service discovery support. for dependency emulator, the core logic is the REST file based parser and load it with custom service host and hook up with service discovery. |
|
We have an independent repository for the Frontend (React/Next/TS) and another for the Backend: C# and and .NET with several services. |
|
What are you doing today to work across multiple repos? |
|
David Fowler (@davidfowl) I have the same problem as a1-jesper I got Codex to write a script that wraps my three repos together so I can atleast launch them together with this script. 
I still end up with three Aspire dashboards I would love if Aspire had multi-repo support in natively and I had one Aspire start command and one dashboard for the services living in different repos. param(
[string] $Root,
[string] $MaesterCloudPath,
[string] $WebsitePath,
[string] $KermitPath,
[switch] $NoKillPorts,
[switch] $UseCurrentTerminal
)
$ErrorActionPreference = "Stop"
function Resolve-RepoPath {
param(
[string] $ExplicitPath,
[string] $RepoName
)
if (-not [string]::IsNullOrWhiteSpace($ExplicitPath)) {
return (Resolve-Path $ExplicitPath).Path
}
$scriptRoot = Split-Path -Parent $PSCommandPath
$repoRoot = Resolve-Path (Join-Path $scriptRoot "..")
$siblingRoot = Split-Path -Parent $repoRoot.Path
if (-not [string]::IsNullOrWhiteSpace($Root)) {
$siblingRoot = (Resolve-Path $Root).Path
}
$candidate = Join-Path $siblingRoot $RepoName
if (-not (Test-Path $candidate)) {
throw "Could not find $RepoName at $candidate. Pass an explicit path parameter or -Root."
}
return (Resolve-Path $candidate).Path
}
function Assert-Command {
param([string] $CommandName)
if (-not (Get-Command $CommandName -ErrorAction SilentlyContinue)) {
throw "Required command '$CommandName' was not found on PATH."
}
}
function Get-PortProcessIds {
param([int] $Port)
if ($IsWindows) {
return @(Get-NetTCPConnection -LocalPort $Port -ErrorAction SilentlyContinue |
Select-Object -ExpandProperty OwningProcess -Unique)
}
$output = & lsof -tiTCP:$Port -sTCP:LISTEN 2>$null
if ($LASTEXITCODE -ne 0 -or [string]::IsNullOrWhiteSpace($output)) {
return @()
}
return @($output -split "\s+" | Where-Object { $_ } | ForEach-Object { [int]$_ } | Select-Object -Unique)
}
function Stop-Ports {
param([hashtable] $Ports)
if ($NoKillPorts -or $UseCurrentTerminal) {
return
}
foreach ($entry in $Ports.GetEnumerator() | Sort-Object Name) {
$port = [int]$entry.Value
$pids = @(Get-PortProcessIds -Port $port | Where-Object { $_ -and $_ -ne $PID })
if (-not $pids.Count) {
continue
}
Write-Host "Stopping process(es) on port $port ($($entry.Name)): $($pids -join ', ')"
foreach ($processId in $pids) {
try {
Stop-Process -Id $processId -Force -ErrorAction Stop
}
catch {
if (-not $IsWindows) {
& kill -TERM $processId 2>$null
Start-Sleep -Milliseconds 300
if (Get-Process -Id $processId -ErrorAction SilentlyContinue) {
& kill -KILL $processId 2>$null
}
}
}
}
}
}
function New-CommandFile {
param(
[string] $Name,
[string] $WorkingDirectory,
[string] $Command
)
$safeName = $Name -replace "[^A-Za-z0-9_.-]", "-"
$path = Join-Path ([IO.Path]::GetTempPath()) "maester-cloud-dev-$safeName.command"
$content = @"
#!/bin/zsh
set -e
cd "$WorkingDirectory"
printf '\033]0;$Name\007'
echo "==> $Name"
echo "cd $WorkingDirectory"
echo "$Command"
echo
$Command
"@
Set-Content -Path $path -Value $content -Encoding UTF8
chmod +x $path
return $path
}
function Start-AspireWindow {
param(
[string] $Name,
[string] $WorkingDirectory,
[string] $LaunchProfile = "http"
)
$command = "ASPIRE_ALLOW_UNSECURED_TRANSPORT=true ASPIRE_DASHBOARD_UNSECURED_ALLOW_ANONYMOUS=true aspire start --launch-profile $LaunchProfile"
if ($UseCurrentTerminal) {
Write-Host ""
Write-Host "[$Name] $WorkingDirectory"
Write-Host $command
return
}
if ($IsMacOS) {
$commandFile = New-CommandFile -Name $Name -WorkingDirectory $WorkingDirectory -Command $command
& open -a Terminal $commandFile
return
}
if ($IsWindows) {
Start-Process pwsh -ArgumentList @(
"-NoExit",
"-Command",
"Set-Location '$WorkingDirectory'; `$Host.UI.RawUI.WindowTitle = '$Name'; $command")
return
}
if (Get-Command gnome-terminal -ErrorAction SilentlyContinue) {
& gnome-terminal --title $Name --working-directory $WorkingDirectory -- zsh -lc "$command; exec zsh"
return
}
throw "No supported terminal launcher found. Rerun with -UseCurrentTerminal to print commands."
}
Assert-Command "aspire"
if (-not $IsWindows) {
Assert-Command "lsof"
}
$maesterCloud = Resolve-RepoPath -ExplicitPath $MaesterCloudPath -RepoName "maester-cloud"
$website = Resolve-RepoPath -ExplicitPath $WebsitePath -RepoName "maester-cloud-website"
$kermit = Resolve-RepoPath -ExplicitPath $KermitPath -RepoName "maester-cloud-kermit"
$ports = @{
"maester-cloud-dashboard" = 18888
"maester-cloud-otlp" = 18889
"maester-cloud-portal" = 5173
"website-dashboard" = 18890
"website-otlp" = 18891
"website" = 4321
"website-api" = 7071
"kermit-dashboard" = 18892
"kermit-otlp" = 18893
"kermit" = 7073
"azurite-blob" = 10000
"azurite-queue" = 10001
"azurite-table" = 10002
}
if ($UseCurrentTerminal) {
Write-Host "Dry run: not stopping ports. Normal startup stops occupied fixed ports unless -NoKillPorts is used."
}
else {
Stop-Ports -Ports $ports
}
Write-Host "Starting Aspire for each Maester Cloud repo..."
Write-Host " maester-cloud: $maesterCloud"
Write-Host " maester-cloud-website: $website"
Write-Host " maester-cloud-kermit: $kermit"
Start-AspireWindow -Name "maester-cloud" -WorkingDirectory $maesterCloud -LaunchProfile "http-fallback"
Start-Sleep -Milliseconds 500
Start-AspireWindow -Name "maester-cloud-website" -WorkingDirectory $website
Start-Sleep -Milliseconds 500
Start-AspireWindow -Name "maester-cloud-kermit" -WorkingDirectory $kermit
Write-Host ""
if ($UseCurrentTerminal) {
Write-Host "Printed 3 aspire start command(s)."
}
else {
Write-Host "Started 3 Aspire window(s)."
}
Write-Host ""
Write-Host "Useful local URLs:"
Write-Host " maester-cloud dashboard: http://localhost:18888"
Write-Host " maester-cloud customer portal: http://localhost:5173"
Write-Host " website dashboard: http://localhost:18890"
Write-Host " website: http://localhost:4321"
Write-Host " website signup API: http://localhost:7071/api/health"
Write-Host " Kermit dashboard: http://localhost:18892"
Write-Host " Kermit: http://localhost:7073"
|
|
Why do you have multiple repos at the moment? |
|
I'm building a SaaS solution which will also have a self-host option. The code for the self-host will be open sourced. The control plan app for the SaaS side of the service (managing tenants etc will not be open sourced). So I'm forced create at least two repositories. The third repo is for the public site and docs. I ideally want it to be in a different repo since content creators will have access to it and I want the control plane repo to be more secure and have limited access compared to the public site/docs repo. Hope that makes sense. |
|
With #18581 for Aspire Roadmap (2026 → 2027), I see this multi-repo support is on the plan as below
looking forward to more detail shared for this support. |
|
This is my take on multi repo support: https://github.com/shirubasoft/aspire-modular-apphosts Probably overly complex but it is based on real needs, I hope the team can take a look at this and make some of it possible. |
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
In several companies that use microservices have their own cloud platform teams and normally this "translates" into having a service per git repos.
In this cases how to use .NET Aspire? Meaning, different projects from different repos? It's not common to have multiple services within the same repo (unless you have a monorepo like Google 😆)
What is your suggestion?
All reactions