[The Architect 2.0]

I have two VS solutions: one the produces a DLL which MVVM Model classes and another that has MVVM View and ViewModel classes.

the View project currently references the build output of the Model project.

The problem is this, for every commit of the View, it is tied to a specific version of the Model DLL. Someone would have to know how to map the commits to each other in both projects...feels kinda stupid.

is there a way to incorporate the DLL into the View project?


I am using a local Git repository btw(no remote Git repo setup yet - hopefully eventually).

ps, not sure which forum to put this into, but i thought it might be good here cause i can't imagine i'm the only person to have this problem.

[tlhIn`toq]

You are aware that one solution can have multiple projects, right?

So if you make a change in one project, that requires a change in the other project you can just increase the version number of each.

Does that point you in a helpful direction, or am I way off base here?

[Raynes]

I'm not entirely sure of the details of what you're doing, but it sounds like you might need git submodules.

[The Architect 2.0]

tlhIn`toq ,

I actually want the Model project DLL to be used by multiple 'View' projects simultaneously. Is what you are proposing appropriate?

my use case:
-open both VS projects
-work on my view, realize that i need to fix a bug in the Model DLL
-switch to the Model project, make a bug fix, build the solution
-switch back to the view. test the bug fix.
-commit the Model changes
-commit the view fixes

[tlhIn`toq]

Short answer: Yes you can have the same project included in many solutions.

Long winded answer:

All that switching sounds like a pain in the ass to me, especially since you don't have the DLL project completed. I understand that you need to develop the DLL side-by-side with the application using it to make everything work right. In my world I simply don't roll out the DLL yet then: Its not done. Just include the project in each solution. Its just a link anyway. So when you open SolutionOne and it uses SharedProject, or you open SolutionThree and it uses SharedProject - they are both using the same SharedProject.

This way you can work on... say the client application all day today... and the server application tomorrow... Each time fine tuning the SharedProject that is used in each of them (and eventually becomes a DLL)

If you build & debug your solution.. then look in its bin directory, you will see that all of your included projects have automatically been turned in into DLL's anyway: This is how it works. You can see it here, corresponding to the earlier example

I have several projects that all share the same 'Common-Functions' project, until they are all done and working. All of those solutions have multiple projects, one of which will eventually become the DLL.

This way I can work on the program in question... realize I need to fine tune the shared method (DLL)... and just fix it... then do more work.

It probably isn't the best plan for a large enterprise where many people are working on lots of interconnected classes. But in those conditions you don't get to make changes to other people's work; you live with it as-is until your written request to them is handled and a new version is rolled out overnight.