xcopy deployment

[cj]

In 2003 to deploy a simple program you could copy the exe from the
projects obj\release directory. Why in 2005 does it create a
bin\release and a obj\release directory, each of which contain what
would appear to be identical exe files?

2005 also puts a debug directory under both bin and obj directories.

 

[zacks]

In 2003 to deploy a simple program you could copy the exe from the
projects obj\release directory. Why in 2005 does it create a
bin\release and a obj\release directory, each of which contain what
would appear to be identical exe files?

2005 also puts a debug directory under both bin and obj directories.

The Debug folder is where the build files are build if the Debug is
selected in the selected configurations.

IMHO, it is best to deploy a project with a .NET Setup project.

 

[cj]

When your dealing with inhouse apps xcopy SHOULD be enough. It's also
nice to KNOW what files are being sprinkled where during installation.
If nothing else it's nice to know what the setup project is actually
doing.

Once completed my projects are moved to a server or pc in the computer
room where they run. It's not like I'm giving a cd with my program on
it to 100 people and saying go copy this exe to whatever pc running
whatever windows version you happen to have. If that were the case a
full blown installation app is needed.

 

[Walter Wang [MSFT]]

Hi cj,

If you open your VB.NET 2005 Project's properties dialog, you will see
"Build output path" in the "Compile" page. This is the path where the built
assembly resides. For default configuration, release mode will output the
assembly in "bin\Release" folder.

The obj folder is only for intermediate files.

Hope this helps.

Sincerely,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your reply
promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jeff Jarrell]

cj,

It's been my observation that while the obj folder is for intermediate files
it also facilitates a work around when projects are using file references as
opposed to project\solution references. It's better now (vs2003 to vs2005),
but since I always use file references to the obj folders, i never get a
failed build because "assembly is in use".

jeff

 

[cj]

That answers my question. Thanks.