vb.net share data

[aaron]

Since I am new to vb.net 2008, I have the following question to ask:
Since a solution (.sln file) can have several projects in it, can one
project file
work with another project file? In other words, can 'object a' in 'project
file 1',
work with 'object b' in 'project file 2' by using methods in ''object b'
where 'properties values' are exposed to 'public' access? For example, can
object 'manage finances' in 'project file 1' obtain the 'checking account'
values from object 'customer' in 'project file 2'? If so, can you tell me
and/or point me to a url that can explain how to accomplish this task?

 

[Armin Zingler]

Am 01.06.2010 15:14, schrieb aaron:

Since I am new to vb.net 2008, I have the following question to ask:
Since a solution (.sln file) can have several projects in it, can one
project file
work with another project file? In other words, can 'object a' in 'project
file 1',
work with 'object b' in 'project file 2' by using methods in ''object b'
where 'properties values' are exposed to 'public' access? For example, can
object 'manage finances' in 'project file 1' obtain the 'checking account'
values from object 'customer' in 'project file 2'? If so, can you tell me
and/or point me to a url that can explain how to accomplish this task?

If one project is a "class library" project, you can reference it from
any other project. In the "set reference" dialog, choose the class library
project on the "projects" folder. Then you can access all available
items from the class library. You may specify the full qualified name
like Classlibrary1.ANamespace.ClassName or "Import" items like within
the same project.

Be aware that every project is made of layers. Every layer can only
access lower layers.

If you have multiple applications (.exe files) that you want to communicate
with each other at run time, you must look for IPC (inter process communication)
in the .Net Framework documentation.

 

[aaron]

:

How about if both projects are not a "class library", can one project in
the same solution access another solution? If so, how would this be setup to
occur?

 

[Armin Zingler]

Am 01.06.2010 17:39, schrieb aaron:

:

How about if both projects are not a "class library", can one project in
the same solution access another solution? If so, how would this be setup to
occur?

If you start an executable, a new process is created. DLLs are libraries that
are loaded dynamically into the process space of a process.

If you have multiple "Exe" projects (Winforms project, Console project) in
the same solution, you can choose which of these projects shall be started
whenever you start debugging. Every executable started is a separate process.
Even if the same Dll (class library) is referenced by different projects and
is consequently loaded into different process spaces, they don't share common
data. Therefore you must use IPC as mentioned.

In the very most cases there is only one Exe project in a solution.

 

[aaron]

I basically have a vb.net 2008 solution that I need to make changes to. I am
trying to determine how this solution (.sln file) is setup. There is no
documentation.
When I compile this application is debug mode, it needs lots of files. If I
compile the .sln file in 'release' mode, the application compiles with a few
warnings.

Basically I am trying to determine how this .sln is setup beofre I make
any changes to it.

Why would buidling in release mode versus debug mode make a difference?
Does it make sense to add a reference to a .dll file in release mode but not
in debug mode?

 

[Armin Zingler]

Am 01.06.2010 22:23, schrieb aaron:

I basically have a vb.net 2008 solution that I need to make changes to. I am
trying to determine how this solution (.sln file) is setup. There is no
documentation.

When I compile this application is debug mode, it needs lots of files. If I
compile the .sln file in 'release' mode, the application compiles with a few
warnings.

Basically I am trying to determine how this .sln is setup beofre I make
any changes to it.

And you should make a backup before changing it. ;-)


First thing you can check are the properties of the solution.
(http://msdn.microsoft.com/en-us/library/09138bex(VS.90).aspx)
Single startup project? Multiple startup projects?

On the project dependencies page (http://msdn.microsoft.com/en-us/library/zk4ahe0t(VS.90).aspx)
you can see on which other project each project depends on. Usually these
are the referenced projects. You can also see them if you open the
project's properties and select the "references" tab.

Why would buidling in release mode versus debug mode make a difference?

It depends on the differences. I mean: you see the differences
by opening the project properties, then you can switch back and forth
between the configurations in the combobox at the top (availabe
on the "Compile" and "Debug" page) to see what's different. On the
"Compile" page, there's also the button "Advanced compile options"
at the bottom. These settings are also configuration dependent.

Are you referring to the warnings you only get with release configuration?
Which kind of warnings?

Does it make sense to add a reference to a .dll file in release mode but not
in debug mode?

The references are not set on a per configuration basis.


BTW, be aware that this group (and all other microsoft.public newsgroups)
will be closed within the next days, weeks or month, as announced for
a few weeks.