473,598 Members | 3,409 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Odd problem with Visual Studio

I have been developing a suite of assemblies over the past couple of weeks,
and this afternoon somethign started misbehaving.

If I do not run the IDE and compiler the code from the command line, the
compilation seems to work properly almost all of the time. More on this
later.

If I launch one copy of the IDE, then I can usually compile the project at
least once. At some point, the build fails reporting "Could not copy
temporary files to the output directory" and then indicates that one of the
DLL could not be copied to the run directory. At this point I cannot even
delete the file from the file explorer until I quit the IDE -- it seems that
something is locking the file!

I have tried to stop and start the IDE, log out and back in and even reboot,
all to no avail. This has been working fine for over two weeks, with me
running teo copies of the IDE -- one for debugging the server component and
one for debugging the client component, both within the same system and
sharing a couple of the assemblies. The DLL is question is one that is used
by the server component only.

The first indication something was different was when I compiled within one
copy of the IDE, started that component, switched to the other IDE, and when
I attempted to start that component running (debugging) it tried to
recompile all of the assemblies again, and this fails since some of the
assemblies are actually being used by the debug session in the other IDE
instance. Since the components that fail are not ones that I needed to
recompile, I generally ignored the problem and kept on debugging. This went
on all day until finally one copy (and now both copies) refuse to
successfully recompile, reporting the above error (on the same assembly).

One thing I should note is that I have all of the assembly projects
configured to place their resulting binaries (DLL or EXE) in the same
directory. This is done to make it easier to debug the applications and
services since the files are kept together.

As part of the checks I made on the project, I deleted all of the files from
the Drive:\Root\Bin \Release and Drive:\Root\Deb ug directories and then
attempted to rebuild from scratch. I did locate one circular reference that
I had introduced, and corrected that, and then I noticed that the *.csproj
files are reference using the relative path to the debug directory, which
meant that if I deleted all files and attempted to build the Release version
it failed! I had to build the debug version first. After thinking about this
I changed all of the project files to reference the dependant DLLs from the
Release directory.

I have not located the problem, and I am still unable to build the solution
and not get this error if even one IDE is running -- but when I lauch and
IDE, I can rebuild the entire solution once!

Does anyoine have any idea why this is happening and what I can do to
correct this?

-Ken
Nov 16 '05 #1
15 2415
Ken Allen wrote:
I have been developing a suite of assemblies over the past couple of weeks,
and this afternoon somethign started misbehaving.

If I do not run the IDE and compiler the code from the command line, the
compilation seems to work properly almost all of the time. More on this
later.

If I launch one copy of the IDE, then I can usually compile the project at
least once. At some point, the build fails reporting "Could not copy
temporary files to the output directory" and then indicates that one of the
DLL could not be copied to the run directory. At this point I cannot even
delete the file from the file explorer until I quit the IDE -- it seems that
something is locking the file!

I have tried to stop and start the IDE, log out and back in and even reboot,
all to no avail. This has been working fine for over two weeks, with me
running teo copies of the IDE -- one for debugging the server component and
one for debugging the client component, both within the same system and
sharing a couple of the assemblies. The DLL is question is one that is used
by the server component only.

The first indication something was different was when I compiled within one
copy of the IDE, started that component, switched to the other IDE, and when
I attempted to start that component running (debugging) it tried to
recompile all of the assemblies again, and this fails since some of the
assemblies are actually being used by the debug session in the other IDE
instance. Since the components that fail are not ones that I needed to
recompile, I generally ignored the problem and kept on debugging. This went
on all day until finally one copy (and now both copies) refuse to
successfully recompile, reporting the above error (on the same assembly).

One thing I should note is that I have all of the assembly projects
configured to place their resulting binaries (DLL or EXE) in the same
directory. This is done to make it easier to debug the applications and
services since the files are kept together.

As part of the checks I made on the project, I deleted all of the files from
the Drive:\Root\Bin \Release and Drive:\Root\Deb ug directories and then
attempted to rebuild from scratch. I did locate one circular reference that
I had introduced, and corrected that, and then I noticed that the *.csproj
files are reference using the relative path to the debug directory, which
meant that if I deleted all files and attempted to build the Release version
it failed! I had to build the debug version first. After thinking about this
I changed all of the project files to reference the dependant DLLs from the
Release directory.

I have not located the problem, and I am still unable to build the solution
and not get this error if even one IDE is running -- but when I lauch and
IDE, I can rebuild the entire solution once!

Does anyoine have any idea why this is happening and what I can do to
correct this?


I assume you have a solution with projects A, B and C, and A references B
and C. Furthermore B and C reference both some given assembly. What I
sometimes see in this scenario is that B or C fail to compile due to this
error. If I first compile B and then C it's ok. You could try to set only one
of the references to copy local is true and the other to copy local is false.
This might solve the conflict.

Another solution (no pun intended) is the separation of some projects into a
separate solution and reference the assemblies from the main solution, not
the projects.

Frans.

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP
Nov 16 '05 #2
On Wed, 28 Apr 2004 01:20:31 -0700, "Frans Bouma [C# MVP]"
<pe************ ******@xs4all.n l> wrote:
Ken Allen wrote:
I have been developing a suite of assemblies over the past couple of weeks,
and this afternoon somethign started misbehaving.

If I do not run the IDE and compiler the code from the command line, the
compilation seems to work properly almost all of the time. More on this
later.

If I launch one copy of the IDE, then I can usually compile the project at
least once. At some point, the build fails reporting "Could not copy
temporary files to the output directory" and then indicates that one of the
DLL could not be copied to the run directory. At this point I cannot even
delete the file from the file explorer until I quit the IDE -- it seems that
something is locking the file!

I have tried to stop and start the IDE, log out and back in and even reboot,
all to no avail. This has been working fine for over two weeks, with me
running teo copies of the IDE -- one for debugging the server component and
one for debugging the client component, both within the same system and
sharing a couple of the assemblies. The DLL is question is one that is used
by the server component only.

The first indication something was different was when I compiled within one
copy of the IDE, started that component, switched to the other IDE, and when
I attempted to start that component running (debugging) it tried to
recompile all of the assemblies again, and this fails since some of the
assemblies are actually being used by the debug session in the other IDE
instance. Since the components that fail are not ones that I needed to
recompile, I generally ignored the problem and kept on debugging. This went
on all day until finally one copy (and now both copies) refuse to
successfully recompile, reporting the above error (on the same assembly).

One thing I should note is that I have all of the assembly projects
configured to place their resulting binaries (DLL or EXE) in the same
directory. This is done to make it easier to debug the applications and
services since the files are kept together.

As part of the checks I made on the project, I deleted all of the files from
the Drive:\Root\Bin \Release and Drive:\Root\Deb ug directories and then
attempted to rebuild from scratch. I did locate one circular reference that
I had introduced, and corrected that, and then I noticed that the *.csproj
files are reference using the relative path to the debug directory, which
meant that if I deleted all files and attempted to build the Release version
it failed! I had to build the debug version first. After thinking about this
I changed all of the project files to reference the dependant DLLs from the
Release directory.

I have not located the problem, and I am still unable to build the solution
and not get this error if even one IDE is running -- but when I lauch and
IDE, I can rebuild the entire solution once!

Does anyoine have any idea why this is happening and what I can do to
correct this?


I assume you have a solution with projects A, B and C, and A references B
and C. Furthermore B and C reference both some given assembly. What I
sometimes see in this scenario is that B or C fail to compile due to this
error. If I first compile B and then C it's ok. You could try to set only one
of the references to copy local is true and the other to copy local is false.
This might solve the conflict.

Another solution (no pun intended) is the separation of some projects into a
separate solution and reference the assemblies from the main solution, not
the projects.


I too have had this same problem. Twas my fault though and feel stupid
saying this. When I was running up test harnesses, there was a bug in
my code and the application was not unloading correctly. The debugger
had stopped, but using task manager I noticed that the process was
still active. Ending the process solved all my problems and I was able
to compile straight away.
Nov 16 '05 #3
You have mis-understood the problem. It is not the compilation that is
failing, but the transfer of the compiled assembly into the target
directory. I can do this once, but then one of the target files gets
'locked' and I cannot delete it until I exit the IDE!

I have put more detail in another posting.

-Ken

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .
Ken Allen wrote:
I have been developing a suite of assemblies over the past couple of weeks, and this afternoon somethign started misbehaving.

I assume you have a solution with projects A, B and C, and A references B
and C. Furthermore B and C reference both some given assembly. What I
sometimes see in this scenario is that B or C fail to compile due to this
error. If I first compile B and then C it's ok. You could try to set only

one of the references to copy local is true and the other to copy local is false. This might solve the conflict.

Another solution (no pun intended) is the separation of some projects into a separate solution and reference the assemblies from the main solution, not
the projects.

Frans.

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

Nov 16 '05 #4
Yes, I thought this was the problem as well, but it has nothing to do with
running the program!

I rebooted (so nothing of my test code is running). At this point I can
compile the code from the command line repeatedly without a problem. I
launch the IDE and open the solution file in debug, and immediately the
build, either from the IDE or from the command line, fails -- the
compilation succeeds but the resulting assembly file cannot be copied to the
target directory, nor can the target file be deleted until I exist from the
IDE.

I am posting more detail in another posting as I have made some progress.

-Ken

"The Real Andy" <.pearson@wayit _dot_com_dot_au _remove_the_obv ious_to_reply>
wrote in message news:hi******** *************** *********@4ax.c om...
On Wed, 28 Apr 2004 01:20:31 -0700, "Frans Bouma [C# MVP]"
<pe************ ******@xs4all.n l> wrote:
Ken Allen wrote:
I have been developing a suite of assemblies over the past couple of weeks, and this afternoon somethign started misbehaving.


I too have had this same problem. Twas my fault though and feel stupid
saying this. When I was running up test harnesses, there was a bug in
my code and the application was not unloading correctly. The debugger
had stopped, but using task manager I noticed that the process was
still active. Ending the process solved all my problems and I was able
to compile straight away.

Nov 16 '05 #5
Ken Allen wrote:
You have mis-understood the problem. It is not the compilation that is
failing, but the transfer of the compiled assembly into the target
directory. I can do this once, but then one of the target files gets
'locked' and I cannot delete it until I exit the IDE!

I have put more detail in another posting.
No, I do have understood your problem, but perhaps formulated it not very
clear. :) One of the locked files has to be overwritten by a copy local
setting which is not possible and compile fails (sometimes you get very weird
errors, sometimes you get a copy error etc.). With webapplications sometimes
index server locks the assemblies in a bin dir and they therefore can't be
overwritten (so stop indexserver from going into these folders), sometimes it
is solved by removing obj folders or set copy-local to false. Have you tried
these settings?

Frans.

-Ken

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .
Ken Allen wrote:
I have been developing a suite of assemblies over the past couple of weeks, and this afternoon somethign started misbehaving.


I assume you have a solution with projects A, B and C, and A references B
and C. Furthermore B and C reference both some given assembly. What I
sometimes see in this scenario is that B or C fail to compile due to this
error. If I first compile B and then C it's ok. You could try to set only

one
of the references to copy local is true and the other to copy local is

false.
This might solve the conflict.

Another solution (no pun intended) is the separation of some projects into

a
separate solution and reference the assemblies from the main solution, not
the projects.


--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP
Nov 16 '05 #6
OK, so I managed to stop the problem from happening, but the solution is odd
and I cannot do release builds properly.

After rebuilding the solution file and one of the project files a couple of
times, I spotted a difference in some of the project files-- and removing
that difference removed the problem! The difference was in the .csproj file
for one or more of the assemblies: in the <References> section there is an
attribute called "HintPath" that indicates where the referenced assembly may
be located -- in most of the projects this was
"..\..\Bin\Debu g\assembly.DLL" , but in at least one of the assembly projects
this read as "..\..\Bin\Rele ase\assembly.DL L"! Once I changed all of the
..csproj files to contain the same path for all of the referenced assemblies
that are generated from the solution, the locked target file (actually one
of the "..\..\Bin\Debu g\assembly.DLL" files) disappeared and I am able to
perform builds without errors once more!

After sleeping on this and coming in again this morning, I found this was
not the case! Some of the project files had been changes somehow during my
investigations, and the problem was being resolved because of the changed
settings. Specifically, some of the assembly outputs were not being directed
to the common target directory, and so the collision did not exist.

So, I started over from scratch, keeping a shadow copy of everything. Here
are the steps I followed:

1. Created an empty solution file and place the SLN and SUO files in the
proper directory.

2. Opened the solution from the IDE and added a new project for the first
class assembly (a class assembly common to the client and server code). I
modified the attibutes on the assembly to send the output to
[..\..\Bin\Debug \] and [..\..\Bin\Relea se\] for the two configurations. I
test built it a few times from the IDE and command line (with the IDE open)
and things are fine.

3. Copied the original source files into the new assembly directory, added
them to the project and removed the dummy "class1.cs" file from the
assembly, and adjusted the references to include the appropriate .Net
libraries. Repeated the build process tests, again with success.

4. Added a new project for the second common class assembly, modified the
output path, set the build order, and tested the build several times. Again
copied the original source files into the directory, added them to the
project and removed the dummy class1.cs file, adjusted the references to
include the appropriate .Net libraries and the first assembly project added
above, and repeated the build tests again.

5. Added a new project for the server-side class assembly, modified the
output path, set the build order, and tested the build several times. Again
copied the original source files into the directory, added them to the
project and removed the dummy class1.cs file, and adjusted the references to
include the appropriate .Net libraries and the two common assembly projects
already added, and repeated the build tests again.

6. Added a new project for a service, modified the project to generate a
console app (defaulted to a Windows app), modified the output path, set the
build order, and tested the build several times. Again copied the original
source files into the directory, added them to the project and removed the
dummy class1.cs file, and adjusted the references to include the appropriate
..Net libraries and the three assembly projects already added, and repeated
the build tests again. The first time it worked, but the subsequent attempts
to build the solution reports that the third assembly added (which
references the first two and is referenced by the serice) could not be
copied to the target directory, and the DLL file for this assembly in the
target directory cannot be deleted from the file explorer until the IDE
exits.

7. Opening the IDE in debug mode causes this problem to reported from a
command line compilation, but leaving the IDE open and simply switching to
Release confioguration (and doing nothing else) permits the command line
execution to proceed! Changing the IDE back to the debug configuration
causes the problem to again be reported on the command line invocation.

8. After some more hair pulling, I finally went to the source directories
for each of the new assemblies, and deleted all of the [obj]
sub-directories -- and this seems to have stopped the problem!!!! I only
thought of this when I deleted all files from the common Debug and Release
target directories and then attempted to do a Release build -- and the Debug
directory got files as well! Very odd!

-Ken

"Ken Allen" <ke******@sympa tico.ca> wrote in message
news:eW******** *****@TK2MSFTNG P11.phx.gbl...
I have been developing a suite of assemblies over the past couple of weeks, and this afternoon somethign started misbehaving.

If I do not run the IDE and compiler the code from the command line, the
compilation seems to work properly almost all of the time. More on this
later.

Nov 16 '05 #7
None of this code is web oriented, it is all client/service code with some
common class assemblies. For the past 16 hours I have not even executed the
code! Nothing is running! The only thing it takes to 'lock' the file in the
common target directory is to open the IDE and select the Debug
configuration!

I have attempted to delete the bin and obj files from the assembly source
directories, but this only helps until the next build!

-Ken

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .
Ken Allen wrote:
You have mis-understood the problem. It is not the compilation that is
failing, but the transfer of the compiled assembly into the target
directory. I can do this once, but then one of the target files gets
'locked' and I cannot delete it until I exit the IDE!

I have put more detail in another posting.
No, I do have understood your problem, but perhaps formulated it not very
clear. :) One of the locked files has to be overwritten by a copy local
setting which is not possible and compile fails (sometimes you get very

weird errors, sometimes you get a copy error etc.). With webapplications sometimes index server locks the assemblies in a bin dir and they therefore can't be
overwritten (so stop indexserver from going into these folders), sometimes it is solved by removing obj folders or set copy-local to false. Have you tried these settings?

Frans.

-Ken

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .
Ken Allen wrote:

> I have been developing a suite of assemblies over the past couple of

weeks,
> and this afternoon somethign started misbehaving.
>

I assume you have a solution with projects A, B and C, and A references B and C. Furthermore B and C reference both some given assembly. What I
sometimes see in this scenario is that B or C fail to compile due to this error. If I first compile B and then C it's ok. You could try to set only
one
of the references to copy local is true and the other to copy local is

false.
This might solve the conflict.

Another solution (no pun intended) is the separation of some projects
into a
separate solution and reference the assemblies from the main solution,

not the projects.


--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

Nov 16 '05 #8
I spoke too soon. This only resolves the problem for 1-2 builds and then the
problem re-occurs.

What puzzles me is that I have not changed the assembly configurations for a
couple of days, although I have been adding code to the specific assemblies.

-Ken

"Ken Allen" <ke******@sympa tico.ca> wrote in message
news:uN******** ******@TK2MSFTN GP09.phx.gbl...
OK, so I managed to stop the problem from happening, but the solution is odd and I cannot do release builds properly.

After rebuilding the solution file and one of the project files a couple of times, I spotted a difference in some of the project files-- and removing
that difference removed the problem! The difference was in the .csproj file for one or more of the assemblies: in the <References> section there is an
attribute called "HintPath" that indicates where the referenced assembly may be located -- in most of the projects this was
"..\..\Bin\Debu g\assembly.DLL" , but in at least one of the assembly projects this read as "..\..\Bin\Rele ase\assembly.DL L"! Once I changed all of the
.csproj files to contain the same path for all of the referenced assemblies that are generated from the solution, the locked target file (actually one
of the "..\..\Bin\Debu g\assembly.DLL" files) disappeared and I am able to
perform builds without errors once more!

After sleeping on this and coming in again this morning, I found this was
not the case! Some of the project files had been changes somehow during my
investigations, and the problem was being resolved because of the changed
settings. Specifically, some of the assembly outputs were not being directed to the common target directory, and so the collision did not exist.

So, I started over from scratch, keeping a shadow copy of everything. Here are the steps I followed:

1. Created an empty solution file and place the SLN and SUO files in the
proper directory.

2. Opened the solution from the IDE and added a new project for the first
class assembly (a class assembly common to the client and server code). I
modified the attibutes on the assembly to send the output to
[..\..\Bin\Debug \] and [..\..\Bin\Relea se\] for the two configurations. I
test built it a few times from the IDE and command line (with the IDE open) and things are fine.

3. Copied the original source files into the new assembly directory, added
them to the project and removed the dummy "class1.cs" file from the
assembly, and adjusted the references to include the appropriate .Net
libraries. Repeated the build process tests, again with success.

4. Added a new project for the second common class assembly, modified the
output path, set the build order, and tested the build several times. Again copied the original source files into the directory, added them to the
project and removed the dummy class1.cs file, adjusted the references to
include the appropriate .Net libraries and the first assembly project added above, and repeated the build tests again.

5. Added a new project for the server-side class assembly, modified the
output path, set the build order, and tested the build several times. Again copied the original source files into the directory, added them to the
project and removed the dummy class1.cs file, and adjusted the references to include the appropriate .Net libraries and the two common assembly projects already added, and repeated the build tests again.

6. Added a new project for a service, modified the project to generate a
console app (defaulted to a Windows app), modified the output path, set the build order, and tested the build several times. Again copied the original
source files into the directory, added them to the project and removed the
dummy class1.cs file, and adjusted the references to include the appropriate .Net libraries and the three assembly projects already added, and repeated
the build tests again. The first time it worked, but the subsequent attempts to build the solution reports that the third assembly added (which
references the first two and is referenced by the serice) could not be
copied to the target directory, and the DLL file for this assembly in the
target directory cannot be deleted from the file explorer until the IDE
exits.

7. Opening the IDE in debug mode causes this problem to reported from a
command line compilation, but leaving the IDE open and simply switching to
Release confioguration (and doing nothing else) permits the command line
execution to proceed! Changing the IDE back to the debug configuration
causes the problem to again be reported on the command line invocation.

8. After some more hair pulling, I finally went to the source directories
for each of the new assemblies, and deleted all of the [obj]
sub-directories -- and this seems to have stopped the problem!!!! I only
thought of this when I deleted all files from the common Debug and Release
target directories and then attempted to do a Release build -- and the Debug directory got files as well! Very odd!

-Ken

"Ken Allen" <ke******@sympa tico.ca> wrote in message
news:eW******** *****@TK2MSFTNG P11.phx.gbl...
I have been developing a suite of assemblies over the past couple of

weeks,
and this afternoon somethign started misbehaving.

If I do not run the IDE and compiler the code from the command line, the
compilation seems to work properly almost all of the time. More on this
later.


Nov 16 '05 #9
Why is the IDE locking these files at all? They are not being locked by any
portion of my application executing since I am not executing anything at
this time other than the IDE!

-Ken

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .
Ken Allen wrote:
You have mis-understood the problem. It is not the compilation that is
failing, but the transfer of the compiled assembly into the target
directory. I can do this once, but then one of the target files gets
'locked' and I cannot delete it until I exit the IDE!

I have put more detail in another posting.
No, I do have understood your problem, but perhaps formulated it not very
clear. :) One of the locked files has to be overwritten by a copy local
setting which is not possible and compile fails (sometimes you get very

weird errors, sometimes you get a copy error etc.). With webapplications sometimes index server locks the assemblies in a bin dir and they therefore can't be
overwritten (so stop indexserver from going into these folders), sometimes it is solved by removing obj folders or set copy-local to false. Have you tried these settings?

Frans.

-Ken

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .
Ken Allen wrote:

> I have been developing a suite of assemblies over the past couple of

weeks,
> and this afternoon somethign started misbehaving.
>

I assume you have a solution with projects A, B and C, and A references B and C. Furthermore B and C reference both some given assembly. What I
sometimes see in this scenario is that B or C fail to compile due to this error. If I first compile B and then C it's ok. You could try to set only
one
of the references to copy local is true and the other to copy local is

false.
This might solve the conflict.

Another solution (no pun intended) is the separation of some projects
into a
separate solution and reference the assemblies from the main solution,

not the projects.


--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

Nov 16 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
6168
by: Martin Bless | last post by:
The good news: Along with Python-2.4 comes really good news to Windows users. Yes, you now CAN build extension modules yourself using the SAME C++ compiler and linker Python is built with itself. Everything you need is available at no costs (except download hassle and installation time). Once your system is set up properly its just a matter of running 'python setup.py build'. No longer waiting for someone else to build binaries and a...
0
6108
by: Tom Lee | last post by:
Hi, I'm new to .NET 2003 compiler. When I tried to compile my program using DEBUG mode, I got the following errors in the C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 \include\xdebug file as folows. I need help to resolve them ASAP: cl /c /nologo /MDd /W3 /Od /GR /GM /Zi /GX /D "_DEBUG" /D " WIN32" /D "_W INDOWS" /D "_WINDLL" /D "_AFXDLL" /D "_MBCS" /D "_USRDLL" /
3
2960
by: fastwings | last post by:
mm the code //////makemenu.h//// class menu { public: int op; pmenu(int op,int sub = 0) { switch op {
2
5729
by: Qiao Yun | last post by:
I used vc++.net (visual studio .net ) to open a project which can work well in vc++6.0. I succeeded in compiling the project in vc++.net in release mode . But when I tried to compile the project in debug mode, the following errors happened: d:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xdebug(29): error C2365: 'new' : redefinition; previous definition was a 'member function' d:\Program Files\Microsoft Visual Studio...
3
1382
by: dean4if | last post by:
I have 4 Windows 2000 Servers. I have installed the DotNet Framework 2.0 on all 4 servers. Three of these servers show a tab for ASP.NET in the IIS MMC and are running Visual Studio 2003. One server that has Visual Studio 2005 installed does not show this ASP.NET tab. On this one server, when I use Visual Studio 2005 to try to create or open a
1
1918
by: ligong.yang | last post by:
Hi all, I got tortured by a very weird problem when I was using k. wilder's random generator class in my program. PS: wilder's generator class can be found at http://oldmill.uchicago.edu/~wilder/Code/random/. Firstly, I got the notorious "fatal error C1010: unexpected end of file while looking for precompiled header directive" error when I tried to compile 'randtest.c' provided by wilder.
3
6048
by: Edwin Smith | last post by:
I have a 2 form project in VS2005 that now hangs whenever I try to do anything with the second form. This seems to have started when I added some SQL tables from a Pervasive v.9 database using the Pervasive ODBC driver. The devenv.exe process hangs and will not respond with about 50% cpu usage and about 100 megs of memory used. I am running it on an Athlon 64 bit dual core with 32 bit Windows XP pro. I have 2 megs of memory so I don't...
0
6664
by: marathoner | last post by:
I am currently migrating my Visual C++ 6.0 applications to Visual Studio 2005. I am getting compiler errors involving the VS2005's platform SDK. When I removed directory references to that SDK, and started using the Microsoft Platform SDK for XP SP2, the errors disappeared, but I am now getting numerous warnings (macro redefinitions) as follows: StdAfx.cpp WINVER not defined. Defaulting to 0x0502 (Windows Server 2003) C:\Program...
2
4130
by: BruceWho | last post by:
I downloaded boost1.35.0 and built it with following command: bjam --toolset=msvc-7.1 --variant=release --threading=multi -- link=shared --with-system stage and it failed to compile, error message is: E:\software\development\boost_1_35_0\boost_1_35_0>bjam -- toolset=msvc-7.1 --variant=release --threading=multi --link=shared --
2
3388
by: Cramer | last post by:
So, what is the relationship between Visual Studio and Visual Web Developer. I find a lot of documentation on MSDN that presents Visual Web Developer as it's own stand-alone product (which I'd expect of the Express editions), but apparently there are NON Express versions of Visual Web Developer. Is Visual Web Developer only built-in to Visual Studio 2008 Professional? I see "Microsoft Visual Web Developer 2008" listed as an installed...
0
7902
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
8395
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
8398
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
8265
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
6719
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
5850
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
1
2412
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
1
1504
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
1250
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.