Sorry, a bit of a noobish question here...spent an hour on Google and in MSs help documents, my head appears to be in the wrong place, I can't figure this out.
I have a C# project set up in Visual Studio 2012 that has references to a few .dlls that I have on my own hard drive (NetOffice .dlls to be specific, for Excel Interop). I've been adding them by right clicking on my references folder, going to Add Reference and then going to Browse to find the files. At that point they are included and everything works as expected on my side.
The problem occurs when I share the project. I'm using Git to keep the project coordinated between myself and a couple team members. I'll run my commit and push it then have my teammate do his pull. Everything shows up on his computer correctly, but when we open up the project it tells me that the NetOffice .dlls are missing.
I'm guess that this is because the files are only linked locally on my computer, but I can't figure out, for the life of me, how to make the .dlls exist in the file structure so that they travel with the project when I push it.
We have a few NuGet packages we use as well, and they seem to work just fine after being transferred. I've also gone into the .dll properties for NetOffice and turned "Copy Local" to true, yet it's still not included.
All I want is to be able to link references and then send the whole thing (dlls included) to my teammate, what am I doing wrong? I figured I would want to simply include the .dlls in the project structure but... I'm just not understanding something. Any help please?
1 Create a folder in the file system at the same level as the solution file.
2 Copy the external dll's to that folder.
3 Add a Solution Folder tho the solution.
4 Add each dll to the the solution folder using add existing item
5 Reference the Dll's in the solution
The steps 3 and 4 aren't really necessary, but they help to keep things organized.
Lets assume your source control root folder is called SourceRoot
and your solution files are under a folder called JaySolutionFolder
I prefer:
Adding a new folder to your source control, under SourceRoot, called SharedDlls
Copy all external Dlls to this Folder.
Add this dll references form SharedDlls to your project.
Commit this folder
Now your teammates have to get JaySolutionFolder & SharedDlls to compile the sources.
Later this SharedDlls could be target directory of Build process (Using tools like TFS Bulid, NANT or else)
This will be a way to minimize team based development problems.
In release and software installation, you can use installers or software package builders like installshield or Visual Studio Setup Package or ... to solve external dlls problem
Hop this helps.
Although it's not good practise to include binaries in your git repository, doing so will solve your problem.
The quick fix could be to create lib directories in sensible locations within your repository (I'm not a C# developer but Gama Felix's suggestion seems correct).
Then commit these folders and push to the server.
Related
I want to convert my program into something that I can give out and people can use (just to my friends and people I know) but I'm totally lost as of how to do it. I've tried doing lots of things from other forums but none seem to work or actually do what I'm looking for.
I tried using the publishing feature in the build tab but don't like that It makes It into a ClickOnce application as I'd much rather have it as an .exe.
From what I read there is already one of these in the bin\debug folder (I'd use the use the release bin\ folder when I am fully finished) but i don't know how much or what files actually need to be packaged together for it to work on another computer.
My main questions are:
Can I actually make a distributable a application using the bin\debug .exe with all the other files in it?
Do I also need to include the obj and properties folder? (I'm guessing not for the properties but the obj does look kind of important)
Because I've used NuGet packages and references do i have to to include the App.config and packages.config or is this just something that visual studio uses?
sorry if I've got anything wrong with what I've said, I'm way out of my comfort zone here.
For a console application, you should be able to zip up the contents of the bin/release directory and distribute it directly.
You can safely exclude .pdb files from your archive, though they can help you debug the program if your friends and cohorts encounter errors.
I have some library files needed for my application to work.
My application has a setup and deployment included.
I already know that in order for a library file to be added to the output directory of the application when installing, I just have to reference those libraries inside the .NET IDE before building... the only problem is that these libraries can't be referenced... So I need to be able to copy these libraries to the installation directory of my application... At the moment, I am copying these libraries manually...
Addendum
I also did try to add these library files as an Existing Item to my project and marked each library files' Copy to Output Directory to Copy if newer on their properties but still not getting the solution I want.
Update 1
Thanks for you help guys it helped me solve my problem, I managed to make the solutions you posted work except for one... #Matthew Watson's post.. I even managed to find a solution too so I wanted to share it with you also.
Heres what I did:
I opened the setup and deployment project in my application.
Under the Application Folder Tree, on it's right side, I right clicked..
then clicked Add..
then clicked File
and then browsed for the files I wanted to add to the installation directory
and click open.
But out of curiosity...I am still trying to make what #Matthew Watson posted work...
Update 2
I forgot to update this post yesterday, I already manage to make Matthew Watson's solution worked yesterday. Thank you again for all your help guys.
You can add files to your project and select their properties: "Build Action" as "Content" and "Copy to output directory" as "Copy Always" or Copy if Newer (the latter is preferable because otherwise the project rebuilds fully every time you build it).
Then those files will be copied to your output folder.
This is better than using a post build step because Visual Studio will know that the files are part of the project. (That affects things like ClickOnce applications which need to know what files to add to the clickonce data.)
You will also be more easily able to see which files are in the project because they will be listed with the source code files rather than hidden in a post-build step. And also Source Control can be used with them more easily.
Once you have added "Content" files to your project, you will be able to add them to a Visual Studio 2010 Setup and Deployment project as follows:
Go into your Setup project and add to your "Application Folder" output the Project Output called "Content Files". If you right-click the Content Files after adding them you can select "outputs" and see what it's going to copy.
Note that Setup and Deployment projects are NOT supported in Visual Studio 2012.
You can use Visual Studio Post Build Event - Copy to Relative Directory Location. Which are basically scripts that are executed on build of specified project.
So you can use it to copy binaries you need, before actually running your application.
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've created a Codeplex site for an app I'm building and right now I just right click the entire solution folder Visual C# Express created for me, and used that.
Now in my repo I have a lot files that I'm assuming will enable the user to compile my application on their end.
I heard I shouldn't upload the /obj folder and some other things.
What things are absolutely necesary for me to commit to my repository?
You should ignore the following, by setting the svn:ignore property on your project folder:
bin
obj
*.user
*.suo
You need the solution file, the C# project file(s), and all of the code files.
Basically, leave out the .suo file (with the solution), any user specific files (which will have your username appended to them, the bin\ and the obj\ folders. Everything else should be included.
It's common practice in organizations I've worked with to also include binary resources to which we don't have the source code and are required for the build in the source control. I'm aware that this is a somewhat controversial practice but it's worked wonders for us. Usually we keep them in a solution-rooted folder named 'Resources' or the like such that they're available for each developer to use when they check out the solution.
If you would use the Standard Edition of Visual Studio you could use the AnkhSVN Plug-In, but in Express this is not possible. :-(
So what you should exclude
folder obj
folder bin
file *.user
file *.ncb
Everything else has to be in your repository.
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.