why x86 folder exist in obj folder in c Sharp project file?
My project file structure is
ProjectOne
----------Bin
--------------Debug
--------------Release
----------Obj
--------------x86 //Why this?
-------------------Debug
-------------------Release
----- My source files.
Why my file current Directory is bin\debug, not projectOne (where my source file exists)?
When executing, the current directory will default to wherever the executable is - which will be in your bin/debug directory.
You can set where you want it to run from when you start it in Visual Studio though (in the project properties - if you need more details, please say exactly which version/edition of VS you're using).
As for the contents of the obj directory - you can pretty much ignore the whole directory. It's full of intermediate files that Visual Studio builds and then consumes - but you almost never need to use any files from there directly.
The x86 folder refers to the target platform for your build in your build configuration manager. It allows you to build 32 bit applications on a 64 bit OS. As Cody and Jon say you can ignore the obj directory.
The bin folder contains your application's binary files (that is, your executables). It is subdivided into two (or more) folders—typically Debug and Release. These correspond to your build configurations. When your project is compiled, the executable files are placed into one of these folders, depending on which type of build you conducted. If you want to run your executable outside of the development environment, you can click on the ".exe" file you find in one of these folders.
If you wish, you can change where Visual Studio outputs your executable files during a compile using your project's Properties window.
The obj directory contains intermediate (or object) files that Visual Studio builds when compiling your application. It's not really something you ever need to worry about or use the files from.
Finally, your source files are kept in the root directory, as displayed in your Solution Explorer window. You manage the locations of these files yourself; they are not managed by Visual Studio.
Object files (the files stored in Obj) are compiled binary files that haven't been linked. Think of it as fragments of the final executable that will later be combined to make your executable.
When compiling your source code each source file will loosely be compiled to one object file. Why? No reason*, just how your particular compiler was written. There are other compilers in other languages that does not do this but instead compile everything into a single large binary in one step. But the people who wrote your compiler decided to first compile to separate object files.
Now, you can imagine that if each source file generate one object file then every time you compile code your source directory will end up being messy and be filled with lots of .obj files (and indeed a lot of C compilers traditionally did this). Over time, developers working on large projects started to write compile script or configure their projects to collect all .obj files in a single directory to make the source directory less messy.
The people who wrote your compiler obviously liked the idea of a separate Obj directory so they made it the default configuration of projects. As for why there is an x86 subdirectory that's because your compiler also supports other CPUs like ARM (for Android, Win Phone 7 and iPhone) and also to differentiate between 32bit and 64bit.
* note: There are actually some very good reasons to do this including making the compiler code more modular and to support incremental compilation but the fact that some people can do all that without generating separate obj files mean that it is mostly a design decision by the developers of the compiler more than it being a necessity.
Related
I've recently coded a little program to determine numbers in a picture and it is reliant on two libraries I've used. (DLLs)
Since my target computer is not allowed to install programs due to security reasons, I need to create a portable .exe.
.NET is installed on the target computer but for some reason VS still does not include the libraries I've used in the exe but instead creates an application folder with a setup.exe, some .DEPLOY files and an application manifest.
I am new to VS and .NET in general so this question could be easy to answer, but I'm asking since I've found nothing useful on StackOverflow neither on google.
You can simply build the application and copy your bin/Debug folder along, but that would still mean you need multiple files.
In order to merge all references into the executable, use ILMerge. Here is some help calling ILMerge.
Basically, after building, you should do something like this:
ilmerge /target:winexe /out:SelfContainedProgram.exe
Program.exe ClassLibrary1.dll ClassLibrary2.dll
There is just one file you need to send along.
One way to do this is to build your application in Release mode (You can pick from Debug or Release in the drop-down). Then go to C:\Projects\[ProjectName]\[ProjectName]\bin\Release (The location of your project folder may vary). You'll see a bunch of files but all you really need are the DLLs, executable, and the config if you used one. You won't have to do any setup if you keep the necessary files in the application's folder, just copy them all to a folder on the target computer, create a shortcut if you want then you're good to go.
You can just copy all your assemblies into any folder you want. Simply chose "Build" from within Visual Studio and copy the files from bin/debug to your destination-folder.
However you have to ensure that all (relative) paths (if existing) still work as you cannot be sure where the user of your program copies the files to.
One simple way could be to use 7zip Packager, it doesn't need any installer. However, VisualStudio method might be more reliable.
I encountered the same issue recently. ILMerge suggestion above is no longer supported. I found Fody.Costura as a modern replacement.
I've built against the release profile and this creates an executable build within the release directory in my project.
How do I best distribute to clients from this executable? There are a lot of files within this folder which don't appear when installed through the installer, such as the mainifest and one called application.exe.xml (which is confusing when Windows hides the extension in Windows Explorer).
Are these all necessary? Can I just send the executable? Or will I need to send with all the files? Is there a way to build without all these files?
You must send the EXE file and any DLL file that you reference locally. If you use COM references and the like, you need to register them during the installation. The same thing for the GAC I think, but I haven't used that for stand-alone applications myself.
The application.exe.config file contains the application settings (a copy of app.config). If you don't use settings or the user doesn't typically care about them, you can omit the file, and it will use the default values you built the application with.
The vshost files are not needed (if you have them). They are used by Visual Studio's debugger. The .pdb files contain debug data used to facilitate DLL file to source matching. Unless you plan on attaching a debugger to the application, there is no point sending those.
Usually, in an XCopy deployment you have to deploy (literally copy all files deployment with no setup/installer program) the content of the output folder (like debug or release) without:
*.pdb - debug symbols
*.xml - xml documentation
?vshost? - Visual Studio hosting files
In fact, it anyway also depends on your specific application. As a developer, you need to know what you are producing; in case you are using an xml file which is not the result of the .NET documentation compiler, but a static file copied in the output folder, then do not forget to deploy it.
A last note: developers usually disable the option to hide file extensions in Windows Explorer ;-)
You need to understand what an installer does or why an installer is important.
An installer takes care of the basic environment. The installer can carry dependent assemblies/modules along with the application. It can also check if you need something before you run, like .NET on the target machine. It can also create the shortcuts on the desktop or start menu. Plus it also provides adequate options on the target machine to uninstall it.
If you wish to ship the executable alone, you might miss out some assemblies that the executable depends on. The target machine may or may not have the correct .NET version installed.
Use the program: HM NIS EDIT from HM Soft.
Build your project
Run NIS EDIT
Make a new script from the wizard (Ctrl + W)
Run all the steps
Select all the .dll and .exe files
Build a setup file
I'm new to using Visual Studio, and I'm trying to figure out how to 'publish' my program so I can move it other's computers and run it from there. I'm not sure if it makes a difference, but there are three projects in my solution. And if I publish it, will I still continue to be able to develop the original files etc?
Thanks a lot!
Ok, so you've written your code, debugged it and now you want to distribute it...
When you build a solution using Visual Studio the compiled output of each project is produced in a folder which is either specified manually, or, by default, in a bin folder relative to the projects root folder. Within this folder are subfolders which hold the output for a corresponding build (for instance the Debug folder contains the Debug compilation output).
If you have three projects then, for example, let's assume one is an executable application and the other two are dynamic link libraries on which the application project is dependent, the compiled output from the latter two projects will automatically be copied to the applications compiled output folder, meaning you only need to ship what is in this folder (along with anything else you actually know is required).
For a (rough) folder graph to try and visualise what I'm saying:
SolutionFolder\
ApplicationProjectFolder\
Bin\ <- contains overall output
Debug\ <- the compilation you develop with
Release\ <- the compilation you distribute (after testing)
DynamicLinkLibrary0Folder\
Bin\
Debug\ <- automatically copied to 'ApplicationProjectFolder\Bin\Debug'
Release\ <- automatically copied to 'ApplicationProjectFolder\Bin\Release'
DynamicLinkLibrary1Folder\
\Bin
Debug\ <- as above
Release\ <- as above
You can continue to work on your code after distributing, yes, of course, but you can hardly expect the users of the application to have your latest changes without redistributing the whole thing, or updating/patching et cetera.
Of course, this solution is the simplest form - ideally you'd want an installer project as part of the solution, which is the final distributable end-product.
As I said above, it seems you may need to know a heck of a lot more than this to proceed competently and confidently, and I could explain further details on each aspect mentioned here, no doubt, but it has to stop somewhere. Hope this gets you started, though.
Adding to the answer given by #Mr. Disappointment, you could also add a Setup project to the solution, which will take the compiled output and build an installer (a .msi file) for your program. You can then give the .msi file to your users and they can run the setup program to install the application on their computers. You can also put the .msi file on a network share or make it available for download from a website, depending on your requirements.
Another option is to investigate Visual Studio's ClickOnce deployment, which also allows you to distribute your application to users in a simplified way, via a web site or network file share.
I have a quick question regarding debug and release in VS 2008.
I have an app i've been working on - its not yet complete but the bulk of the functionality is there. So basically i'm trying to give a copy of it now to the person helping with documentation - just so they can have a play and get the feel for what i've made.
Now the question is how to provide it to them. I was told to just copy the .exe out of the debug/bin folder and put that onto USB. But when testing, if I run this .exe anywhere else (outside of this folder) it crashes. I've now worked out why this is:
var path = ConfigurationManager.AppSettings["PathToUse"];
var files = Directory.GetFiles(path);
throws a null reference, so that App.config file is not being used. If I copy that file in with the .exe it works again.
So actually my question is regarding the best way to manage this situation. What is the best way to provide a working copy to people, and, is there a reference on preparing apps for release - so everything is packaged together and installed in a clean structured folder heirarchy?
If you want to be safe grab everything in the debug/bin folder. If you use the drop down in VS to change to release and then compile the project, there will be fewer files in the release/bin folder because many debug related files are not included.
If there are third party DLLs you are referencing, like if you downloaded log4net or something like that, then you can simply put them in the same folder as the exe. This is called side-by-side deployment, and in my opinion is the simplest and easiest to test.
You can search for XCOPY deployment to learn more about what you are trying to do.
You can take another step of compressing the bin folder into an archive like a zip file to make it easy for the user to extract them, or you could use a tool like WIX or NSIS to create an installer to extract and copy the files.
For some reason, we have a script that creates batch files to XCOPY our compiled assemblies, config files, and various other files to a network share for our beta testers. We do have an installer, but some don't have the permissions required to run the installer, or they're running over Citrix.
If you vomited all over your desk at the mentions of XCOPY and Citrix, use it as an excuse to go home early. You're welcome.
The code currently has hundreds of lines like:
CreateScripts(basePath, "Client", outputDir, FileType.EXE | FileType.DLL | FileType.XML | FileType.CONFIG);
It used to be worse, with 20 int parameters (one per file type) representing whether or not to copy that file type to the output directory.
These hundreds of lines create upload/download batch files with thousands of XCOPY lines. In our setup projects, we can reference things like "Primary output from Client" and "Content Files from Client". I'd love to be able to do that programmatically from a non-setup project, but I'm at a loss.
Obviously MS does it, either using an API or by parsing the .csproj files. How would I go about doing this? I'm just looking for a way to get a list of files for any of the setup categories, i.e.:
Primary Output
Localized Resources
Content Files
Documentation Files
EDIT:
I have a setup project like Hath suggested, and it's halfway to what I'm looking for. The only problem keeping that from being a perfect solution is that multiple projects depend on the same assemblies being in their own folder, and the setup will only copy the file once.
Example:
Projects Admin, Client, and Server all rely on ExceptionHandler.dll, and Admin and Client both rely on Util.dll, while Server does not. This is what I'm looking for:
Admin
Admin.exe
Admin.exe.config
ExceptionHandler.dll
Util.dll
Client
Client.exe
Client.exe.config
ExceptionHandler.dll
Util.dll
Server
Server.exe
Server.exe.config
ExceptionHandler.dll
Since the referenced assemblies are all the same, what I get is this:
Admin
Admin.exe
Admin.exe.config
ExceptionHandler.dll
Util.dll
Client
Client.exe
Client.exe.config
Server
Server.exe
Server.exe.config
This causes a FileNotFoundException when either Client or Server can't find one of the two DLLs it's expecting.
Is there a setup property I'm missing to make it always copy the output, even if it's duplicated elsewhere in another project's output?
EDIT AGAIN: All referenced DLLs are set to "Copy Local", and always have been. I found a decent article on using NAnt and XSLT to grab the list of files, so that may be a possible solution as well, as neouser99 suggested.
ACCEPTED SOLUTION: I'm pretty much back where I started. All .exe and .dll outputs are put into a "bin" directory in the setup project, loosely packed. The other per-application folders contain shortcuts to the executable in that directory.
The difference now is, I'm going to add a custom action to the installer to use reflection, enumerate the dependencies for each executable output, and copy the .exe and .dll files to the separate directories. Bit of a pain, as I just assumed there was a way to programmatically detect what files would be included via some setup library.
why not use another setup project and just set the 'Package files' setting to As Loose uncompressed files (setup project->properties)? then share the folder.. or something.
edit:
I see, you have 3 folders for your outputs. but the setup project only detects the ExceptionHandler.dll and Util.dll once, so it will just pick the first folder and put it in there.
You could do a setup project for each project - bit annoying maybe..
You could manually add in the dll's to the projects that are missing the assembly's
either by adding in the File by 'add file' or 'add assembly' or 'add project output' if you have those projects in the same solution.. (I doubt that's the case though).
or just dump all of them into one output directory...
Although it's designed as a build tool, you might find NAnt to be extremely useful in what you are talking about. The tasks (build, copy, move, delete, etc.) that you can define allow for very fine-grained file lookups, up to general, full folders. If you also incorporate NAnt into your build process, I think you could find that it helps out in more ways then one.
Another approach that has worked for me in the past is to add the shared resource (Assembly, DLL or project) as a reference to each of the Admin, Server and Client projects. Then open the properties panel for the referenced item in each project and set "Copy Local" to true.
Now when you build the projects, each will have its own instance of the Assembly copied into its output folder.
This should also cause the shared components added in this manner to be replicated in each of the output folders in the setup package.
A completely different approach could be to set them up as symbolic links on the network share. A symbolic link is basically a short-cut where the file-system hides the fact that it is a short-cut, so all other applications actually believes that the file has been copied (http://en.wikipedia.org/wiki/NTFS_symbolic_link).
One advantage of this approach is that the file is updated immediately as the file changes and not only when you build your projects. So when you for instance save one of the config-files with a text-editor the update is applied immediately.
The following MSBuild script part can build your SLN file (you can replace it with .csproj) and will report a list of all projects that were build (Dlls, EXEs).
<MSBuild Projects="MySolution.sln" Targets="Clean; Rebuild" Properties="Configuration=$(BuildMode);">
<Output TaskParameter="TargetOutputs"
ItemName="AssembliesBuilt" />
</MSBuild>
Now, this doesn't really solve your problem, but it gets you a list of everything that was build. You also have copylocal, so you could probably just take AssembiesBuild and copy all DLL and .CONFIG files from there.
Example:
AssembliesBuild = c:\myproj\something1\build.dll
you'd go to c:\myproj\something1\ and simply search for all *.dll and *.config files and include them. You can do this pretty easily with MSBuild or powershell, if you have it installed. To output a XCOPY script from MSBuild, I think you'll need MSBuild contrib projct installed.