-
|
Hello, I am currently exploring the capabilities of .NET Aspire, particularly its service discovery features and the shared functionalities provided by ServiceDefaults. As of now, to leverage these features, it seems necessary to house all our projects within the same solution. This arrangement functions well when the projects are relatively small or when there are only a few microservices. However, as projects expand—consider scenarios with 5-6 deployable components, each encompassing multiple layers—merging them into a single solution becomes increasingly cumbersome. Not only would the build process become significantly prolonged, but navigating through the projects and managing them effectively would also prove challenging. This could detrimentally affect the development experience. In light of these challenges, I have opted to maintain the deployable components and their respective layers in separate solutions. However, this approach currently precludes me from utilizing .NET Aspire to its full extent. Therefore, I would like to inquire whether there is a possibility to configure .NET Aspire to work with applications distributed across different solutions. Any guidance or suggestions on how to achieve this would be greatly appreciated. Thank you for your time and assistance. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 22 replies
-
|
Is your plan to clone all of the source code for each solution locally? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's correct. Each solution is run independently when necessary. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I meant when you need to run multiple solutions and have them communicate. What do you do today? Are you hard coding urls to talk cross repo etc etc? In summary, in a world without aspire, when you do need to run multiple repos together and have them communicate, how do you do it? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's precisely what I do. To enable communication across multiple solutions, I hardcode URLs within the appsettings files of each application. Additionally, there are a few hardcoded database connection strings as well. Given that my application operates across multiple environments—such as test, development, and production—I manage and adjust these hardcoded values accordingly to ensure they're correct for each specific environment. |
Beta Was this translation helpful? Give feedback.
-
|
Great! That's great information. We have lots of work to do in this area so this sort of information is very useful. I think one thing we will end up doing in some form is making for a more first-class way to reference another apphost project. You need to be able to build a new apphost project that references another one and lets you mutate and reference connection information and references in a more loosely coupled way. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much for taking the time to consider my situation and for planning to address it. It’s reassuring to know that the challenges I’ve encountered are being taken into account as you work on enhancing .NET Aspire. I wish you all the best in these development efforts. Additionally, I would be interested to know if there is any way for me to track the progress on this topic. Will there be a task, feature request, or any other form of tracking identifier that I could follow for updates? |
Beta Was this translation helpful? Give feedback.
-
|
That references a similar topic I opened a while ago. I would like to run container images, reference them, and provide resources to them #1912 |
Beta Was this translation helpful? Give feedback.
-
|
@gkfischer I think generally container images alone aren't enough to make this end to end smooth. You want to abstract a set of resources and expose the ability to hide them. If you we're going to do the same with libraries, you would build a nuget package that exposed a method that wires up the container and its dependencies (transitively). |
Beta Was this translation helpful? Give feedback.
-
|
I thought that a running container started from an image isn't so much different than a container started from a solution file. But docker stuff isn't really my thing. To me it seems that a container running a microservice isn't so much different than a container providing let's say Redis. It's a running thing in Docker, exposing ports. But maybe I'm on the wrong flight level. |
Beta Was this translation helpful? Give feedback.
-
|
Currently, there are 257 projects in the solution, while sometimes I only want to focus on the aspire dashboard project, and think maybe some projects could be moved out to the community/aspire repo to keep the aspire focused on the core functionalities |
Beta Was this translation helpful? Give feedback.
Great! That's great information. We have lots of work to do in this area so this sort of information is very useful. I think one thing we will end up doing in some form is making for a more first-class way to reference another apphost project. You need to be able to build a new apphost project that references another one and lets you mutate and reference connection information and references in a more loosely coupled way.