So, to answer with some screenshots:
First create your two projects. The project that is the startup project (in your example and in mine, that would be Project1) needs to know about the other solution. To do this, we need to add the reference to the project, right click on Project1 and click on 'Add reference...'
Then, use the solution option in the sidebar, to click the checkbox on Project2
And then you can add the project in your code using the Project2.Form1 identifier, as such
Public Class Form1
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
Dim frmOtherProject As New Project2.Form1
frmOtherProject.Show()
End Sub
End Class
or, in case your form in the second project doesn't have a biased name (form1 currently exists 2 times, so lets rename it as form2), you can import the second project and use it's classes directly as such
Imports Project2
Public Class Form1
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
Dim frmOtherProject As New Form2
frmOtherProject.Show()
End Sub
End Class
I used Visual Studio 2012 as a basis, but the principle should be the same ;)
ADDITION
I might point out that this will not be your typical style of referencing the projects, mostly you will separate your application by levels of concern, by adding, for example:
- An entitylayer, that contains your models, and is referenced by all other layer (solutions)
- A datalayer that can load/save your models and serve them, this is referenced by the "business logic layer" and references the entitylayer itself
- A business logic layer, that references the datalayer and the entitylayer and that is referenced inside the presentation layer, it doesn't know anything about which database you are using, it just serves as an intermediary between your presentation layer (which is what the user sees) and the datalayer, and only handles the entities defined in your entity layer
- And long last, the presentation layer, that references the entity layer and the business logic layer, it to doesn't need to know which database is serving the data, but only presents the data in a useful way to it's users
There are of course plenty of ways to arrange your application in a meaningful structure, but I find that this one is a good example on how you can structure your application in a meaningful way
UPDATE
As an update still, getting your solutions to share code, shouldn't be this hard, if you write your code so that it can be reused. By sharing the logic and the harder code inside a class library that can be shared over both solutions, you only have to rewrite the Presentation layer (how you display the data). And you can do it more specifically for the environment you want to work with.
In the end, your Outlook Addin Solution and Your windows forms project could share the code that requests the resources, or loads the data, or does some other complex calculations, and the only code you have to "reproduce" is how you show it on the screen. So according to the environment you can present the data in a better way, specific to that environment, but share the logic and the models you use in both (or more) environments.
This way, you development time is cut down, and your code becomes less error prone, because you don't have the same code several times, as an example, see the following screenshot:
As you can see, there is a shared library, that is referenced by the outlook addin and by the windows form application. Neither the Forms application nor the outlook application know about each other, and they also shouldn't, as they have essentially nothing to do with the other.
So, although, my latest update doesn't answer your question, I still think it's the better way to arrange your code. If you would later want to make a website reusing the code you made, you only need to make an extra presentation layer, and reuse the code from the SharedLibrary once again.
