Why Do Rererences Get Switched?

[Robert W.]

I have a VS2003 WinForms app with a main project called "Desktop". It
references a DLL I've also created called "DataTransfer".

When setting up the references of Desktop I specifically chose the
DataTransfer.dll file WITHIN DataTransfer\bin\Debug

When I run the project, everything works fine and I can step through the
code of DataTransfer (which runs in a different thread by the way).

But then later on and definitely after a Rebuild the reference gets changed
to point to the DataTransfer.dll in Desktop\bin\Debug. The app still runs
but I can no longer step through the code in DataTransfer.

Why is this happening and how I can prevent it?

--
Robert W.
Vancouver, BC
www.mwtech.com

[Scott M.]

When you compile an assembly, unless you give it a strong name and register
it into the GAC, it will be a "Private" assembly. When you make a reference
to a private assembly, you get a copy of that assembly brought into your
project and that is what your project works off of, not the original. This
is done so that multiple versions of an assembly can be used by different
applications easily.
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:84**********************************@microsof t.com...

I have a VS2003 WinForms app with a main project called "Desktop". It
references a DLL I've also created called "DataTransfer".

When setting up the references of Desktop I specifically chose the
DataTransfer.dll file WITHIN DataTransfer\bin\Debug

When I run the project, everything works fine and I can step through the
code of DataTransfer (which runs in a different thread by the way).

But then later on and definitely after a Rebuild the reference gets
changed
to point to the DataTransfer.dll in Desktop\bin\Debug. The app still runs
but I can no longer step through the code in DataTransfer.

Why is this happening and how I can prevent it?

--
Robert W.
Vancouver, BC
www.mwtech.com

[Robert W.]

Scott,

Thanks for your response. I also just noticed that in the Project
Properties there's a section entitled References Path. One can actually
change the order.

How things got out of order, I do not know, but I just forced the source
folder to the top of the list and now everything works perfectly again!

--
Robert W.
Vancouver, BC
www.mwtech.com

"Scott M." wrote:

When you compile an assembly, unless you give it a strong name and register
it into the GAC, it will be a "Private" assembly. When you make a reference
to a private assembly, you get a copy of that assembly brought into your
project and that is what your project works off of, not the original. This
is done so that multiple versions of an assembly can be used by different
applications easily.
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:84**********************************@microsof t.com...

I have a VS2003 WinForms app with a main project called "Desktop". It
references a DLL I've also created called "DataTransfer".

When setting up the references of Desktop I specifically chose the
DataTransfer.dll file WITHIN DataTransfer\bin\Debug

When I run the project, everything works fine and I can step through the
code of DataTransfer (which runs in a different thread by the way).

But then later on and definitely after a Rebuild the reference gets
changed
to point to the DataTransfer.dll in Desktop\bin\Debug. The app still runs
but I can no longer step through the code in DataTransfer.

Why is this happening and how I can prevent it?

--
Robert W.
Vancouver, BC
www.mwtech.com

[rmacias]

Why not just the DLL to your solution and reference it through the "Projects"
tab instead of browsing for it? That will also elimenate your problem. When
you Rebuild your solution, you'll always use the latest copy of the DLL.

"Robert W." wrote:

Scott,

Thanks for your response. I also just noticed that in the Project
Properties there's a section entitled References Path. One can actually
change the order.

How things got out of order, I do not know, but I just forced the source
folder to the top of the list and now everything works perfectly again!

--
Robert W.
Vancouver, BC
www.mwtech.com

"Scott M." wrote:

When you compile an assembly, unless you give it a strong name and register
it into the GAC, it will be a "Private" assembly. When you make a reference
to a private assembly, you get a copy of that assembly brought into your
project and that is what your project works off of, not the original. This
is done so that multiple versions of an assembly can be used by different
applications easily.
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:84**********************************@microsof t.com...

I have a VS2003 WinForms app with a main project called "Desktop". It
references a DLL I've also created called "DataTransfer".

When setting up the references of Desktop I specifically chose the
DataTransfer.dll file WITHIN DataTransfer\bin\Debug

When I run the project, everything works fine and I can step through the
code of DataTransfer (which runs in a different thread by the way).

But then later on and definitely after a Rebuild the reference gets
changed
to point to the DataTransfer.dll in Desktop\bin\Debug. The app still runs
but I can no longer step through the code in DataTransfer.

Why is this happening and how I can prevent it?

--
Robert W.
Vancouver, BC
www.mwtech.com

[Robert W.]

Hi There,

I've re-read your first sentence 3 times but don't understand the wording.
Could you rephrase in another way?

--
Robert W.
Vancouver, BC
www.mwtech.com

"rmacias" wrote:

Why not just the DLL to your solution and reference it through the "Projects"
tab instead of browsing for it? That will also elimenate your problem. When
you Rebuild your solution, you'll always use the latest copy of the DLL.

"Robert W." wrote:

Scott,

Thanks for your response. I also just noticed that in the Project
Properties there's a section entitled References Path. One can actually
change the order.

How things got out of order, I do not know, but I just forced the source
folder to the top of the list and now everything works perfectly again!

--
Robert W.
Vancouver, BC
www.mwtech.com

"Scott M." wrote:

When you compile an assembly, unless you give it a strong name and register
it into the GAC, it will be a "Private" assembly. When you make a reference
to a private assembly, you get a copy of that assembly brought into your
project and that is what your project works off of, not the original. This
is done so that multiple versions of an assembly can be used by different
applications easily.
"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:84**********************************@microsof t.com...
>I have a VS2003 WinForms app with a main project called "Desktop". It
> references a DLL I've also created called "DataTransfer".
>
> When setting up the references of Desktop I specifically chose the
> DataTransfer.dll file WITHIN DataTransfer\bin\Debug
>
> When I run the project, everything works fine and I can step through the
> code of DataTransfer (which runs in a different thread by the way).
>
> But then later on and definitely after a Rebuild the reference gets
> changed
> to point to the DataTransfer.dll in Desktop\bin\Debug. The app still runs
> but I can no longer step through the code in DataTransfer.
>
> Why is this happening and how I can prevent it?
>
> --
> Robert W.
> Vancouver, BC
> www.mwtech.com
>

[rmacias]

I had to re-read it too :) Sorry it's late.

You have your solution that contains your "Desktop" project. Right click
your solution and point to "Add" and then click on "Existing Project".
Browse for your project file for you Data Transfer DLL project file (*.cproj).

Your solution will now have two projects. Now right click your "Desktop"
project and click on "Add Reference". Select the "Projects" tab and it will
list the avaliable projects in your solution. Select the "DataTransfer"
project.

Now everytime you re-compile your solution, Data Transfer will recompile and
it will be copied to your Desktop projects bin directory every time.

When you deploy your application, you can put DataTranser.dll in either the
same directory as Desktop.exe or in the GAC.

"Robert W." wrote:

Hi There,

I've re-read your first sentence 3 times but don't understand the wording.
Could you rephrase in another way?

--
Robert W.
Vancouver, BC
www.mwtech.com

"rmacias" wrote:

Why not just the DLL to your solution and reference it through the "Projects"
tab instead of browsing for it? That will also elimenate your problem. When
you Rebuild your solution, you'll always use the latest copy of the DLL.

"Robert W." wrote:

Scott,

Thanks for your response. I also just noticed that in the Project
Properties there's a section entitled References Path. One can actually
change the order.

How things got out of order, I do not know, but I just forced the source
folder to the top of the list and now everything works perfectly again!

--
Robert W.
Vancouver, BC
www.mwtech.com

"Scott M." wrote:

> When you compile an assembly, unless you give it a strong name and register
> it into the GAC, it will be a "Private" assembly. When you make a reference
> to a private assembly, you get a copy of that assembly brought into your
> project and that is what your project works off of, not the original. This
> is done so that multiple versions of an assembly can be used by different
> applications easily.
>
>
> "Robert W." <Ro*****@discussions.microsoft.com> wrote in message
> news:84**********************************@microsof t.com...
> >I have a VS2003 WinForms app with a main project called "Desktop". It
> > references a DLL I've also created called "DataTransfer".
> >
> > When setting up the references of Desktop I specifically chose the
> > DataTransfer.dll file WITHIN DataTransfer\bin\Debug
> >
> > When I run the project, everything works fine and I can step through the
> > code of DataTransfer (which runs in a different thread by the way).
> >
> > But then later on and definitely after a Rebuild the reference gets
> > changed
> > to point to the DataTransfer.dll in Desktop\bin\Debug. The app still runs
> > but I can no longer step through the code in DataTransfer.
> >
> > Why is this happening and how I can prevent it?
> >
> > --
> > Robert W.
> > Vancouver, BC
> > www.mwtech.com
> >
>
>
>

[Robert W.]

Thank you for that tip. I had never tried that approach before.

Something strange happened when I did it though. I got over a 1,000 warning
about various system items being defined in multiple places.

Here's an example:

C:\Documents and Settings\Robert Werner\My Documents\Visual Studio
Projects\PocketPollster\Desktop\frmMain.cs(646,37) : warning CS1595:
'System.Drawing.Font' is defined in multiple places; using definition from
'c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.Drawing.dll'
What would cause this to happen?

Just so you know, Desktop references both DataTransfer and DataObjects.
DataTransfer itself references DataObjects.

I don't know if that's the source of the problem though. It seems like
somehow there's some ambiguity about which System object to reference. But I
am only using the .Net Framework 1.1, having never tried 2.0

Any ideas?

--
Robert W.
Vancouver, BC
www.mwtech.com

"rmacias" wrote:

I had to re-read it too :) Sorry it's late.

You have your solution that contains your "Desktop" project. Right click
your solution and point to "Add" and then click on "Existing Project".
Browse for your project file for you Data Transfer DLL project file (*.cproj).

Your solution will now have two projects. Now right click your "Desktop"
project and click on "Add Reference". Select the "Projects" tab and it will
list the avaliable projects in your solution. Select the "DataTransfer"
project.

Now everytime you re-compile your solution, Data Transfer will recompile and
it will be copied to your Desktop projects bin directory every time.

When you deploy your application, you can put DataTranser.dll in either the
same directory as Desktop.exe or in the GAC.

"Robert W." wrote:

Hi There,

I've re-read your first sentence 3 times but don't understand the wording.
Could you rephrase in another way?

--
Robert W.
Vancouver, BC
www.mwtech.com

"rmacias" wrote:

Why not just the DLL to your solution and reference it through the "Projects"
tab instead of browsing for it? That will also elimenate your problem. When
you Rebuild your solution, you'll always use the latest copy of the DLL.

"Robert W." wrote:

> Scott,
>
> Thanks for your response. I also just noticed that in the Project
> Properties there's a section entitled References Path. One can actually
> change the order.
>
> How things got out of order, I do not know, but I just forced the source
> folder to the top of the list and now everything works perfectly again!
>
> --
> Robert W.
> Vancouver, BC
> www.mwtech.com
>
>
>
> "Scott M." wrote:
>
> > When you compile an assembly, unless you give it a strong name and register
> > it into the GAC, it will be a "Private" assembly. When you make a reference
> > to a private assembly, you get a copy of that assembly brought into your
> > project and that is what your project works off of, not the original. This
> > is done so that multiple versions of an assembly can be used by different
> > applications easily.
> >
> >
> > "Robert W." <Ro*****@discussions.microsoft.com> wrote in message
> > news:84**********************************@microsof t.com...
> > >I have a VS2003 WinForms app with a main project called "Desktop". It
> > > references a DLL I've also created called "DataTransfer".
> > >
> > > When setting up the references of Desktop I specifically chose the
> > > DataTransfer.dll file WITHIN DataTransfer\bin\Debug
> > >
> > > When I run the project, everything works fine and I can step through the
> > > code of DataTransfer (which runs in a different thread by the way).
> > >
> > > But then later on and definitely after a Rebuild the reference gets
> > > changed
> > > to point to the DataTransfer.dll in Desktop\bin\Debug. The app still runs
> > > but I can no longer step through the code in DataTransfer.
> > >
> > > Why is this happening and how I can prevent it?
> > >
> > > --
> > > Robert W.
> > > Vancouver, BC
> > > www.mwtech.com
> > >
> >
> >
> >

[rmacias]

Undo the changes you made to the Reference Paths property. In fact, those
should be empty. It sounds like that there could be multiple references to
the same DLL.

"Robert W." wrote:

Thank you for that tip. I had never tried that approach before.

Something strange happened when I did it though. I got over a 1,000 warning
about various system items being defined in multiple places.

Here's an example:

C:\Documents and Settings\Robert Werner\My Documents\Visual Studio
Projects\PocketPollster\Desktop\frmMain.cs(646,37) : warning CS1595:
'System.Drawing.Font' is defined in multiple places; using definition from
'c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Syst em.Drawing.dll'
What would cause this to happen?

Just so you know, Desktop references both DataTransfer and DataObjects.
DataTransfer itself references DataObjects.

I don't know if that's the source of the problem though. It seems like
somehow there's some ambiguity about which System object to reference. But I
am only using the .Net Framework 1.1, having never tried 2.0

Any ideas?

--
Robert W.
Vancouver, BC
www.mwtech.com

"rmacias" wrote:

I had to re-read it too :) Sorry it's late.

You have your solution that contains your "Desktop" project. Right click
your solution and point to "Add" and then click on "Existing Project".
Browse for your project file for you Data Transfer DLL project file (*.cproj).

Your solution will now have two projects. Now right click your "Desktop"
project and click on "Add Reference". Select the "Projects" tab and it will
list the avaliable projects in your solution. Select the "DataTransfer"
project.

Now everytime you re-compile your solution, Data Transfer will recompile and
it will be copied to your Desktop projects bin directory every time.

When you deploy your application, you can put DataTranser.dll in either the
same directory as Desktop.exe or in the GAC.

"Robert W." wrote:

Hi There,

I've re-read your first sentence 3 times but don't understand the wording.
Could you rephrase in another way?

--
Robert W.
Vancouver, BC
www.mwtech.com

"rmacias" wrote:

> Why not just the DLL to your solution and reference it through the "Projects"
> tab instead of browsing for it? That will also elimenate your problem. When
> you Rebuild your solution, you'll always use the latest copy of the DLL.
>
> "Robert W." wrote:
>
> > Scott,
> >
> > Thanks for your response. I also just noticed that in the Project
> > Properties there's a section entitled References Path. One can actually
> > change the order.
> >
> > How things got out of order, I do not know, but I just forced the source
> > folder to the top of the list and now everything works perfectly again!
> >
> > --
> > Robert W.
> > Vancouver, BC
> > www.mwtech.com
> >
> >
> >
> > "Scott M." wrote:
> >
> > > When you compile an assembly, unless you give it a strong name and register
> > > it into the GAC, it will be a "Private" assembly. When you make a reference
> > > to a private assembly, you get a copy of that assembly brought into your
> > > project and that is what your project works off of, not the original. This
> > > is done so that multiple versions of an assembly can be used by different
> > > applications easily.
> > >
> > >
> > > "Robert W." <Ro*****@discussions.microsoft.com> wrote in message
> > > news:84**********************************@microsof t.com...
> > > >I have a VS2003 WinForms app with a main project called "Desktop". It
> > > > references a DLL I've also created called "DataTransfer".
> > > >
> > > > When setting up the references of Desktop I specifically chose the
> > > > DataTransfer.dll file WITHIN DataTransfer\bin\Debug
> > > >
> > > > When I run the project, everything works fine and I can step through the
> > > > code of DataTransfer (which runs in a different thread by the way).
> > > >
> > > > But then later on and definitely after a Rebuild the reference gets
> > > > changed
> > > > to point to the DataTransfer.dll in Desktop\bin\Debug. The app still runs
> > > > but I can no longer step through the code in DataTransfer.
> > > >
> > > > Why is this happening and how I can prevent it?
> > > >
> > > > --
> > > > Robert W.
> > > > Vancouver, BC
> > > > www.mwtech.com
> > > >
> > >
> > >
> > >

[Chris Dunaway]

Robert W. wrote:

Thank you for that tip. I had never tried that approach before.

Project references are the preferred way to reference other assemblies.
Check the following link:

http://msdn.microsoft.com/library/de...ml/tdlg_rm.asp

Look especially at chapter 4, "Managing Dependencies", where it talks
about the advantages of using project references.

[Robert W.]

Thank you both, gentlemen!

Chris, I read the article you cited. Excellent.

"rmacias", I followed your instructions to a T and learned a lot in the
process. Now I much better understand all the referencing in my app and what
I should look for.

Not a bad start to a Thursday morning ... and even before I finished my
first cup of coffee!

Do you all remember the bad old days before the Internet? I do. With the
help of knowledgeable people like you, programming has become a whole lot
easier (less painful) than it was back then!
--
Robert W.
Vancouver, BC
www.mwtech.com

"Chris Dunaway" wrote:

Robert W. wrote:

Thank you for that tip. I had never tried that approach before.

Project references are the preferred way to reference other assemblies.
Check the following link:

http://msdn.microsoft.com/library/de...ml/tdlg_rm.asp

Look especially at chapter 4, "Managing Dependencies", where it talks
about the advantages of using project references.

[rmacias]

You are very welcomed. Glad I can help. Well, I'm only 26, so I grew up as
the Internet was just taking off in the 90's. Although I can't imagine how
anybody got anywhere without Map Quest or Google Maps :)

"Robert W." wrote:

Thank you both, gentlemen!

Chris, I read the article you cited. Excellent.

"rmacias", I followed your instructions to a T and learned a lot in the
process. Now I much better understand all the referencing in my app and what
I should look for.

Not a bad start to a Thursday morning ... and even before I finished my
first cup of coffee!

Do you all remember the bad old days before the Internet? I do. With the
help of knowledgeable people like you, programming has become a whole lot
easier (less painful) than it was back then!
--
Robert W.
Vancouver, BC
www.mwtech.com

"Chris Dunaway" wrote:

Robert W. wrote:

Thank you for that tip. I had never tried that approach before.

Project references are the preferred way to reference other assemblies.
Check the following link:

http://msdn.microsoft.com/library/de...ml/tdlg_rm.asp

Look especially at chapter 4, "Managing Dependencies", where it talks
about the advantages of using project references.