Need Help Understanding Solutions, Projects and Files

I am rewriting an old VB6 Application in VB.Net. As this is my first large vb.net project I need some help understanding the relationship between Solutions, Projects and Files. Here's a summary of my understanding and my questions - I'd appreciate any comments to both correct me if I'm wrong and help guide me on my way.

First, in the VB6 world I had a Solution Folder that contained multiple VBP files. Each VBP had some of its own unique forms and also used some forms that were common to other VBP's - was not a problem since all were in same Solution Folder. Each VBP was compiled into it's own executable and a program selection menu (Another VBP) called the appropriate executable as needed.

Now, in the VB.Net world, a Solution can contain multiple projects and as I understand it, all projects within a solution are compiled into the same executable..... If this is true, how do I have two or more of those projects run at same time?
Also, development code files for each project are kept in separate project folders.... How do we share forms between projects in development? If we need multiple copies of same form it's a maintenance headache.

Is it better to have all compiled projects in one file for distribution or multiple executables as we did in VB6 era.

Any help is appreciated.

Lee

A Project represents the source for a single executable, i.e. either an EXE or DLL file. A solution is basically a handy way to keep multiple related projects together. Generally, to begin with, your solutions will just contain a single project. It's for that reason that VB doesn't even display the solution by default. When you create a Windows Forms application it will create a solution containing that one project. As the whole thing grows, you might find that it becomes prudent to break out some of the functionality into a library. You would then add a new Class Library or Windows Control Library project to your solution. You'd move the appropriate functionality from the first project to the second and then the first project would reference the second in order to access the functionality it contain. When you build, the library project compiles to a DLL and the application project compiles to an EXE. The DLL will be copied to the output folder of the application project along with its EXE and you then deploy both for your application to work.

It's the referencing of one project in another that is the answer to your question. That's exactly how all your projects are able to access all the types in the .NET Framework. Your app only knows what a form is because it has a reference to the System.Windows.Forms.dll assembly that is part of the Framework. Take a look at the References page of the project properties to see what assemblies your project references by default. It's there that you'd add the reference to the second project. Referencing a project amounts to referencing the DLL that it compiles to but without having to change the reference each time you build.

OK - I can follow for the most part but am in need of clarification on the following:

I have three projects.
1. Menu.exe
2. Purchasing.exe
3. WorkOrders.exe

Menu.exe allows user to select either Purchasing or WorkOrders Program.

Both Purchasing and WorkOrders deal with Inventory and consequently both projects use the same Forms and Code when dealing with inventory items.

On my Development system how do I setup my projects so that I only have one copy of the inventory forms shared between both Purchasing and WorkOrders Projects?

If I need to edit the Inventory Forms I want to do it in one central place - don't want to do it twice!

Lee.b

Does it really make sense to have three separate applications? I can't really see why you would have one application that is then used to open one of two other applications. It seems to me that it would make far more sense to just have one application.

Regardless, I already answered your question exactly in my previous post.

Quote:

---

As the whole thing grows, you might find that it becomes prudent to break out some of the functionality into a library. You would then add a new Class Library or Windows Control Library project to your solution. You'd move the appropriate functionality from the first project to the second and then the first project would reference the second in order to access the functionality it contain. When you build, the library project compiles to a DLL and the application project compiles to an EXE. The DLL will be copied to the output folder of the application project along with its EXE and you then deploy both for your application to work.

---

If you want to make use of the functionality in the library in more than one other project then you reference it in more than one other project.

I have to agree with jmcihinney, I don't see a need for three separate apps. Having an app dedicated to nothing more than providing shortcuts to two other programs really doesn't make sense to me. If you must have a menu, then you could have then Menu load at startup and then run the others as separate forms within the same app. Make sure they are modeless and they can still be swapped between just like seperate applications.

Alternatively, you could combine them into a single user interface, maybe using tabs or something, to switch between Purchasing and Work Orders. If you don't like tabs, then you could use a hotkey, drop down menu, or toolbar buttons to swap between the two. Just take the contents of the main form for each application and load them into separate panels and then hide/show the appropriate one.

OK - I can put all into one executable but now here's where I'm running into a problem.

As a test, I created a menu form with two buttons.

Button#1 Click does PurchasingSection.show
Button#2 Click does WorkOrderSection.show

Buttons #1 and #2 each launch the opening form in each section successfully.
Now, the opening form in Purchasing is a table of Purchase Orders. And if I dbl click on one of those PO's another form opens modal (formname.showDialog) displaying the contents of that PO.
Now, because I've got that form open Modal, I can't switch over to the WorkOrder Table and open a WorkOrder.

I guess I don't know proper way of opening forms.
I open Purchase Order Table - That opens PO Add/Edit Form - That can open Either Vendor Table or Inventory Table.
As each form is closed, the previous form is restored.
How do I do this without being Modal? I don't want to close the PO Add/Edit form and leave Inventory or Vendor tables active.

This is the main reason why I'm asking about separate executables. I have 22 different functions comprising of more than 140 forms and reports. Some forms appear in multiple executables.
Also, when updating my customers it's easier to build, QA and replace 6mb a executable rather than rebuild and reinstall over 160mb of program.

Lee.b

Quote:

---

Originally Posted by Lee.B

Buttons #1 and #2 each launch the opening form in each section successfully.
Now, the opening form in Purchasing is a table of Purchase Orders. And if I dbl click on one of those PO's another form opens modal (formname.showDialog) displaying the contents of that PO.
Now, because I've got that form open Modal, I can't switch over to the WorkOrder Table and open a WorkOrder.

I guess I don't know proper way of opening forms.
I open Purchase Order Table - That opens PO Add/Edit Form - That can open Either Vendor Table or Inventory Table.
As each form is closed, the previous form is restored.
How do I do this without being Modal? I don't want to close the PO Add/Edit form and leave Inventory or Vendor tables active.

This is the main reason why I'm asking about separate executables. I have 22 different functions comprising of more than 140 forms and reports. Some forms appear in multiple executables.
Also, when updating my customers it's easier to build, QA and replace 6mb a executable rather than rebuild and reinstall over 160mb of program.

Lee.b

---

If you went all modeless, in the Parent forms .FormClosing event you could add the code to close any child windows that may be open. In the Child windows .FormClosing events, check if data needs to be saved and prompt accordingly. This prevents stray windows getting left open and/or forgotten changes being lost.

Sounds like a workable solution except for some places where I don't want parent active while child is active. - Could corrupt data in the open child.

Quote:

---

Originally Posted by Lee.B

Sounds like a workable solution except for some places where I don't want parent active while child is active. - Could corrupt data in the open child.

---

Just off the top of my head I can think of two easy solutions.

1. If there could be any reason to look back at or copy data from the parent to the child, when the child is opened, you could loop through the controls on the parent and set the "enabled" property to "false".

2. If there is no reason to look back at the parent, when the child is opened, minimize the parent and set a boolean flag to true. In the parent, resize event, re-minimize if the flag is true (preventing it from being brought back up). When the child closes set the flag to false and restore the parent to normal view.

Quote:

---

Originally Posted by Lee.B

OK - I can put all into one executable but now here's where I'm running into a problem.

As a test, I created a menu form with two buttons.

Button#1 Click does PurchasingSection.show
Button#2 Click does WorkOrderSection.show

Buttons #1 and #2 each launch the opening form in each section successfully.
Now, the opening form in Purchasing is a table of Purchase Orders. And if I dbl click on one of those PO's another form opens modal (formname.showDialog) displaying the contents of that PO.
Now, because I've got that form open Modal, I can't switch over to the WorkOrder Table and open a WorkOrder.

I guess I don't know proper way of opening forms.
I open Purchase Order Table - That opens PO Add/Edit Form - That can open Either Vendor Table or Inventory Table.
As each form is closed, the previous form is restored.
How do I do this without being Modal? I don't want to close the PO Add/Edit form and leave Inventory or Vendor tables active.

This is the main reason why I'm asking about separate executables. I have 22 different functions comprising of more than 140 forms and reports. Some forms appear in multiple executables.
Also, when updating my customers it's easier to build, QA and replace 6mb a executable rather than rebuild and reinstall over 160mb of program.

Lee.b

---

That does sound like a reason to consider two separate executables. I couldn't see a reason for separating them before but this is new and relevant information. That does beg the question though, do you want direct interaction between the Purchasing and Work Order sections, e.g. do you want to transfer data between a Purchasing form and a Work Order form? That can be done using separate apps but it is significantly more complex. If you make them separate apps then they are as separate as any other two applications.

I have combined several projects now into one solution and need some help understanding how the Build works. I have set my solution SingleStartup Project to what I want. I am able to do a Build Solution. It appears that Build Solution creates one EXE for each of the projects withing the solution. Is that correct?

My Startup Project (Procedure Menu) then will shell out (Process.start) to the other Procedure EXE's as needed.

I was under the impression that some how all exe's within a solution were combined into one EXE - can you enlighten me on this? Currently they are each in their own project bin folder.

Thanks for your patience with me - just trying to get a better understanding of this environment.

Lee

Every application project is a separate application. If they weren't then you wouldn't be using Process.Start. As has already been explained, each project represents a separate assembly, i.e. EXE or DLL. Each EXE is an application. Each DLL is a library, a reusable component that is accessible to other libraries and applications. Each of your EXEs knows nothing more about each other than any other two applications. That's why I asked the question I did in my previous post, which has gone unanswered.

Jmcilhinney:
Sorry for not answering question - The Purchasing module and the Equipment maintenance Module both require access to inventory and that was somewhat related to my initial question on how to share form files between projects. I did not want to have copies of inventory Add/Edit forms etc in two different projects as that would be a maintenance headache. I have since found that the ADD EXISTING ITEM function provides a Drop Down on the ADD button to add an item or add a link to an item. Using the Add Link I'm able to keep one copy of the inventory forms and share them amongst several projects.


Thanks again for your comments.

Lee

I would suggest not using Add As Link. This can cause major headaches down the line. From everything that's been said I would initially suggest four projects in your solution: 3 applications (your startup application, your Purchasing application and your WorkOrder application) and 1 class library to contain all the forms. You will need to add a reference from the class library to the System.Windows.Forms .NET assembly, and from both the Purchasing and WorkOrder applications to the class library project (.NET and Projects are two different tabs on the Add Reference dialog).
When you build the solution, the class library output (a .dll) will be copied to the output folders of both the Purchasing and WorkOrder applications such that they are able to find it.
I would code your Startup application so that the app.config file contains settings for the paths to the two applications you want to launch (which in your dev environment would be pointing to the respective output folders), thus there need be no reference between those applications, and the startup application will be able to run them without needing to copy them out of their respective output folders.

Moving forward, I would look to eliminate the additional exes, although the exact way you'd deal with it isn't immediately obvious off the top of my head. Bear in mind though that there is no concept of a 'modal' dialog at the Win32 API level. For some background reading that may or may not be useful, have a look at this:
http://blogs.msdn.com/b/oldnewthing/.../10246541.aspx

[Edit: And to stop you worrying about copying the dll to two different places (if it wasn't obvious) - if you copy both Purchasing and WorkOrder exes to a single folder, you only need one .dll in that folder.]

Evil_Giraffe:
Am now investigating method you suggest and have some questions on proper way of coding, referencing and navigating the class library.
I have setup a simple main form in one project that does the following:
1. on form load, executes a function from the class library and displays the text.
2. on Button Click sends some text to the class library form text then displays the form from Class Library
3. Class Library Form has button to load another form within the same class library.

Please look at code below and let me know if I'm doing this correctly and if there's a better way to do it.

Your comments are appreciated.

Lee

Main Form Code:

Code:

---

Imports CommonClass
Public Class Form1

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load

        Label1.Text = Class1.GetSomeText()  ' get some text form function in Class1 of CommonClass Library

    End Sub

    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click

        Dim myform As New FormS1            'Do I need to Instantiate a form from the class?
        myform.Text = "The Form"                              'why not just formS1.text?
        myform.Show()

    End Sub
End Class

---

Class Library Code:

Code:

---

Public Class Class1
    Public Shared myVariable As String = "Some Common Data Variable"  'is this the proper way to declare global variables

    Public Shared Function GetSomeText() As String
        Return "Text message"

    End Function

End Class

Public Class FormS1

    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        Dim locffrm As New CommonClass.LocalForm  ' Here we're accessing a "Local" form within the class library
        locffrm.Show()                                        'why not just LocalForm.show?
    End Sub
End Class

---

To answer your 'why not just <FormName>.<Whatever>?' - as far as I know there would be no reason that wouldn't work. You would be using Default Instances, but as long as you are aware of that and are happy to use them, that's fine. I personally wouldn't even think to use Default Instances as I'm primarily a C# developer where they're not available, but I know of many VB developers that purposefully avoid them. I think if I did the majority of my coding in VB that I would fall in that camp as well.

I think if you were looking to unify the applications further down the line you would definitely be wise to avoid Default Instances now (as the best way of dealing with the issues of Default Instances is to adopt an All or Nothing approach: either use DIs everywhere or use them nowhere. Clearly with a unified application, you want to reuse the form for both Purchasing and WorkORder which implies using two different instances at the same time. That rather rules out Default Instances Everywhere, leaving you with the options of Default Instances Nowhere or Horrendous Mess. :)

If I reference a Class Library Form from either main Program or from a form within the class library this way it works fine.
Assuming Imports CommonClass

Dim myform As New FormS1
myform.Show()

If however I just reference the form name as:
FormS1.show

I get error "Reference to a non-shared member requires an object reference"

So, will need to Instantiate forms from class library before loading or referencing - correct??

Lee

Oh, yes of course you will need to do that, now I stop and think about it. The way Default Instances work is that it generates a MyProject.Forms shared class behind your back and transforms all the calls to that. As you may guess from the name, that is scoped to the current project, so a form in one project won't have a Default Instance available from another project.

E-G:
Thanks for your comments - Look forward to working with you again at some time in the future.

Lee.b