What I do for this is to prepend the path to my data files in a config file. For my dev environment I point to their location on my computer. The same config file on our servers points to the location there. I've been bitten by "relative to the binary" before ;-)
I've recently taken it one step further in part to work around the problem where strongly typed datasets generate code that spews thousands of missing sml comment warnings. All my schemas, xml data files, static pdfs (used as templates for dynamically built pdfs), public keys and the like are in a shared project now. I build the project, to get the dll for the s.t. datasets, and then include the project in all my deployments. The deployment is done with NAnt. Still pretty new but so far I like it. --- Ben Kloosterman <[EMAIL PROTECTED]> wrote: > Actually I have some Xml Datafiles ( eg Data\Items) and I want them in > Debug\Bin\Data\Items to match the final distribution. > > The program scan this directory and loads in the data at startup. It would > be nice having it in one location and letting Visual Studio copy them during > the build. Make files should do the trick. I will try sourceforge ( it is > down or blocked at the moment.) > > Ben Kloosterman > > > -----Original Message----- > > From: Moderated discussion of advanced .NET topics. > > [mailto:[EMAIL PROTECTED]]On Behalf Of Philip Nelson > > Sent: Thursday, 19 December 2002 10:49 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [ADVANCED-DOTNET] Copying files when building projects > > > > > > Do you really need them in the bin/debug directory? I would think > > a vs macro > > would probably do the trick, though it's a separate click to > > execute. Perhaps > > a vs macro that first builds and then copies. > > > > > > --- "Shawn A. Van Ness" <[EMAIL PROTECTED]> wrote: > > > The sample project accompanying my NDoc article [1] includes a > > "VC++ makefile > > > project" which copies some files around, post-build, in order > > to feed NDoc. > > > > > > [1] http://www.oreillynet.com/cs/user/view/cs_msg/12137 > > > > > > I'm sure you can figure out the VC++ makefile trick yourself, > > Ben. But if > > > you want a quick sample project, to copy around... well, there you go. > > > > > > Until VS.NExT offers an explicit solution for this (and rumor > > has that it > > > will) it's worth your while to learn the postbuild-makefile > > trick. IMHO. > > > > > > Cheers, > > > -Shawn > > > http://www.arithex.com/ > > > > > > > > > > > > On Wed, 18 Dec 2002 14:59:13 +0800, Ben Kloosterman > > > <[EMAIL PROTECTED]> wrote: > > > > > > >Is there anyway to copy files to the output directory for non web > > > >applications? > > > > > > > >I have a project with XML data files . The data files are > > included in the > > > >project and set to Content and have the extention of .ITL.Xml > > . They do not > > > >get copied to the bin/debug directory of the project they are > > part of or the > > > >startup Winfrom projects' bin/debug directory. Am i missing > > something ? Or > > > >do I have to attach a batchfile with an xcopy to the build > > process and if so > > > >how. > > > > > > > >Would you advice using C++ make files instead ? > > > > > > > >Ben > > > > > > > >You can read messages from the Advanced DOTNET archive, > > unsubscribe from > > > Advanced DOTNET, or > > > >subscribe to other DevelopMentor lists at http://discuss.develop.com. > > > > > > You can read messages from the Advanced DOTNET archive, unsubscribe from > > > Advanced DOTNET, or > > > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > > > You can read messages from the Advanced DOTNET archive, > > unsubscribe from Advanced DOTNET, or > > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > > > > > You can read messages from the Advanced DOTNET archive, unsubscribe from > Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
