I have multiple web projects in one solution with several requiring others to be running in order to function. For example, project A may require projects E and F to be running and Project B may require Projects F, G, and H to be running.
Is there a way to have visual studio manage these dependencies so that when I go to debug project A, projects E & F also starts automatically? I know I can set multiple startup projects in order to make sure both projects startup when I go to debug, but this means that when I go to run project A, I need to have memorized which other projects also need to be set to startup and the same for all of the rest of the projects, each of which has different requirements for running.
Maybe remove runnable projects to separate solutions, and class libraries to one or more solutions which you will reference when needed...
This way, you will run what you need and when needed only, and reduce number of references you have...
Then, you may run everything manually, or create some automated build system with, for example, dashboard app, which will build and you can chose what to run and what do you need active...
Also, keep project specific code inside a project solution, and move shared class libraries to shared solutions, in order to keep your code clean and not duplicated...
If done well, this could lead to lots of code decoupling and simpler app diagram...
Go to your solution and right click on the main one and select Set Startup projects... then pick Multiple startup projectsand if you want to projectB runs before projectA then just move it using the arrows so projectB is above to project A
If needing more assistance, you can also check this official documentation:
https://learn.microsoft.com/en-us/visualstudio/ide/how-to-set-multiple-startup-projects?view=vs-2019
Related
we are working on many different applications where each application has its own VS solution (and of course a CS project). Additionally there are many libraries (also CS projects) that are shared between the applications and are included in the VS solution so that you can debug during startup phase of the development.
We also have a "master" solution that contains all projects in one big solution for refactoring issues. Because VS does not support "solutions in solutions" we have to maintain also this master solution. We are talking about 300 assemblies.
Now a point is reached where it's helpful anymore to have all CS projects as ProjectReference in the application solution anymore. For example we have a library that does the CUDA support which can be compiled once and then used as a regular Reference.
The only problem here is that there are occasions where you need the ProjectReference back again when you need to debug into a problem that can only be verified when it runs in conjunction with the main application and cannot be verified in a normal test case.
One option would be to maintain two projects, one for debugging and one for working. The only problem is that once you debug and you need to use the ProjectReference the dependencies cascade down the whole project tree.
For me it feels like that I need two CS projects for each project. One that only contains References and another one that only contains ProjectReferences. Mixing could be a problem. The question is, if there is something automatic where a Referency-only project can be created from a ProjectReference-only project?
How do you solve something like this?
I'm writing a program in C# that has two classes, Foo and Bar. I have two executables that will use them, GenerateFooBar and SearchFooBar. My question is how should my solution be partitioned? From what I can gather, everything can live in one solution and each executable should have it's own project. Should Foo and Bar
share a project?
each have their own projects?
go with one of the other projects?
something else?
Thanks for the help! I'm coming from Java if that's helpful.
In your solution, create project called for example Common, and put all your classes and businbes logics there. Set project type as Class Library
Next add your other projects and in them Add Reference to Solution Common project to use it.
If multiple users are meant to work with the shared library, the best solution will be to create the local nugget
Create a shared project and put Foo and Bar into it. Reference that project from both executable projects.
If you later have many developers depending on the shared library you might make it into a Nuget package that you publish and have them depend on that.
From what I can gather, everything can live in one solution and each
executable should have it's own project.
Yes, you are right.
how should my solution be partitioned?
Totally depends on you and how you would like to manage it.
You could create one project, multiple projects, each separated projects, etc.
But, to reuse code as much as we can and to give a more structured way. Here is what you can do.
Make one Project which will hold the ApplicationServices, Helpers, etc eg: Foo and Bar.
Make Another Project which will hold the application itself (Could be two projects one for search and one for generate). You can add reference of service project to your foo and bar projects and to any other project you create in future.
So in the end you will have 2 or 3 projects (depending on you)
1- ApplicationServices
2- Generators/GeneratorServices/GenerateApplications/anyname
3- Search/SearchServices/SearchApplications/anyname
I have a large solution which is built daily in TFS. The solution covers multiple logical sub solutions - e.g ApplicationA which consists of projects A,B,C,D; ApplicationB which consists of projects A,B,E,F, ApplicationC which consists of projects A,C,G,H.
Currently we make a copy of the build solution file locally and unload projects we don't need to build to work on a project - so for ApplicationA we'd unload everything other than A,B,C,D.
Another approach would be to create multiple solution configurations which would only build projects A,B,C,D for ApplicationA - but I fear this would be cumbersome and the .sln file would end up huge.
The issue is that many projects are brought together into one wix package and installed together - so the main .sln file makes sense, especially from a build point of view but also debugging.
Maintaining multiple solution files doesn't seem right as when new projects are added we'd need to add them to multiple solutions. So perhaps the configuration method is the way to go, but it doesn't feel right either.
Does anybody have experience of a similar scenario, and how did you get around it?
It sounds like it would make sense to have five solution files:
Master.sln, contains all projects
ApplicationA.sln, contains projects A, B, C, D
ApplicationB.sln, contains projects A, B, E, F
ApplicaitonC.sln, contains projects A, C, G, H
It's fine to have all of those solution files in the same top-level directory.
But maintaining multiple solution files isn't feasible as when new projects are added we'd need to add them to multiple solutions.
Why is that a problem? You need to work out which applications the project is required by anyway... Create the project in the master solution (which will definitely need it) and then use "Add existing project" for the solutions which need it. It's really not that much work - and I wouldn't expect that new projects are added that often anyway. (If they are, that's an indication of a bigger problem.)
The project that I'm currently working on is being developed by multiple teams where each team is responsible for different part of the project. They all have set up their own C# projects and solutions with configuration settings specific to their own needs. However, now we need to create another, global solution, which will combine and build all projects into the same output directory.
The problem that I have encountered though, is that I have found only one way to make all projects build into the same output directory - I need to modify configurations for all of them. That is what we would like to avoid. We would prefer that all these projects had no knowledge about this "global" solution. Each team must retain possibility to work just with their own sub-solution.
One possible workaround is to create a special configuration for all projects just for this "global" solution, but that could create extra problems since now you have to constantly sync this configuration settings with the regular one, used by that specific team. Last thing we want to do is to spend hours trying to figure out why something doesn't work when building under global solution just because of some check box that developers have checked in their configuration, but forgot to do so in the global configuration.
So, to simplify, we need some sort of output directory setting or post build event that would only be present when building from that global, all-inclusive solution. Is there any way to achieve this without changing something in projects configurations?
Update 1
Some extra details I guess I need to mention:
We need this global solution to be as close as possible to what the end user gets when he installs our application, since we intend to use it for debugging of the entire application when we need to figure out which part of the application isn't working before sending this bug to the team working on that part.
This means that when building under global solution, the output directory hierarchy should be the same as it would be in Program Files after installation, so that if, for example, we have Program Files/MyApplication/Addins folder which contains all the addins developed by different teams, we need the global solution to copy the binaries from addins projects and place them in the output directory accordingly.
The thing is, the team developing an addin doesn't necessary know that it is an addin and that it should be placed in that folder, so they cannot change their relative output directory to be build/bin/Debug/Addins.
The key here is that team is responsible for a deliverable. That deliverable is a collection of binaries. So the "global" solution ... or "product that uses the deliverables from teams" is interested in ensuring that all of the 'current deliverables' work together. That is, that you have a deliverable from the collaborative effort.
So this begs a few questions. Do the team deliver what they consider to be a 'release'. This may be automatic in the build system. If it builds and all tests pass then publish it.
What you are looking for is a team publishing or promoting a release. The source code is how you got there, the binaries are the result. Each team controls what binaries it considers to be a release (this may be automated by the build system).
Not exactly what you asked, but I hope it is the answer that leads to the right questions to give good results.
One very simple way would be to create the solution. Include all the projects and add a project (or more) to handle the global solution build tasks. The projects in the global solution should then have a reference to the projects they need and then let Visual Studio handle how to get the binaries from each project. They will (under normal circumstances) be copied to the output folder of the build project. So the project added specifically for the global build tasks would have a copy of all the referenced projects
Another way would be to create a global MSBuild script that references the rest of the build scripts. Each project is on it's own a MSBuild script
EDIT
From the comments it would seem that there are two categories of projects. One that needs building and one that does not.
For those that need building reference them as projects in the aggregating project for those that do not require building add them either as references or add the dll as resources.
Using the later change the property of the Build action to None and copy to output directory to Copy if newer
In both cases you now have all dll's in the output directory you can then have a post build action on the aggregating project moving the dlls that should be in a specific folder (ie not in the output folder)
Have a look at the practice of Continuous Integration and the usage of a Build Server with scripted builds. This is an indispensable instrument when developing different parts of an application as a team, and your problems are a great illustration of the reason why.
You've not mentioned if you use a Version Control system. I've found in practise that each developer maintains his/hers/their teams configuration and builds locally on there machine, since you don't check *.suo or *.user files most of the personal configuration only affects the individual team member.
On a completely seperate machine check-out the same code from all repositories and compile the project on the build machine (this can be completely automated). This maintains your build servers independance.
Don't worry about it being a "Solution". You can easily build multiple solutions one after the other.
Since the output path is relative (and probably "bin\Debug") it'll get built wherever you check it out to. If you want all the binaries in the same output folder you could tweak the output path on every configuration to match. Something like "....\bin\Debug" (obviously this affects where the projects get built to on the local machines but it might not matter). That way multiple projects would get built the same target output.
You could also include a seperate setup build on the build server which isn't on each developers local machine to package up the final product.
I have a simple project that is used in lots of other solutions. Whenever I update this project I have to remember to go into the other solutions that use this project and recompile and deploy as well.
Is there a way to automate this?
If you use any sort of continuous integration tool like TeamCity, Jenkins, or Cruise Control, you could have your commits automatically cause the other solutions to be built.
I'm always uneasy about any solution that doesn't require a recompile when an API you depend on changes. Updating something that acts as a module without rebuilding makes sense, but if something you depend on changes you really want to make sure that doesn't break things elsewhere.
Using a CI server will allow you to run any sort of testing you want on each individual solution and notify you of a failure on one of them. You can also add steps for things like packaging a deployment or if you really enjoy playing with fire you could have the CI server do the deploy automagically.
Edit: Typically this is all done on an integration server, but there is no reason you couldn't set it up on your local machine.
If you're using any form of continuous integration e.g. cruise control, teamcity, TFS etc then you can easily set up your CI to rebuild you're dependent soutions.
Another less elegant solution may be to either have a .sln file that contains all of your projects and work in that solution.
Alternatively, you could add a post build event that build the dependent solutions when you make a change.
Mark those projects as Build/Deploy in Configuration Manager
You probably missing that.
That sounds very scary, actually. You make a change to a single project, and then, without regression testing all its dependent projects are automatically recompiled with the new version and deployed?
If you manage to find a way to do this, I predict great turmoil and calamity.
Is the reused project a class library? If so, what I usually do is add a reference to the dll in the output bin of the class library. Whenever I recompile the dll, the other projects almost immediately detect it (specially Intellisense.)
This doesn't work for dependent projects that are already deployed, though.
Beside having a build server setup, that would launch the build/publication of the other projects, I don't think so. If you want to check out a continuous build program, we've used "CruiseControl" (http://cruisecontrol.sourceforge.net/) where I use to work, and it was a nice setup with a lot of customized possibilities.