I am trying to create installer file by Visual Studio 2015 Installer.
When I add Primary output from <project name> into Application Folder, it point to files in obj folder instead of bin folder.
After installed, I can NOT start my application. I think the reason come from "obj/Release".
Please refer to attached image for more information:
Why? How can I change it to bin folder?
The easiest thing to do is to forget about primary output and just add the files you want by browsing to them from the IDE's File System view, especially if it's just one or two files, and it typically help to see the files you're installing and know exactly what you're doing. Also, note that other files (such as data files) should most likely be installed to user's application data (not Application Folder), and shared Dlls might need to be in common files folder, and assemblies into the GAC. Using primary output tends to gloss over this kind of detail.
Related
I installed the Visual Studio 2017 Installer and added an installer project to my solution.
When I'm building my main project, I'm using post build events to create a Production directory (in which all files are nicely sorted into directories) - for the sake of the example, let's say that this is the new path: C:\workspace\NewProject\bin\release\Production
I saw that the installer takes the build files (located under the debug/release folder under C:\workspace\NewProject\bin\) and those are the files which will be installed when running the msi.
However, what I wish is that the installer will ignore all files under C:\workspace\NewProject\bin\release and use the files under C:\workspace\NewProject\bin\release\Production
Is that possible? Or should I somehow configure the output folder's files from the installer's properties?
Although the "project output" option is popular as input to setup projects it's often better to just use the Add File of option in the File System view in the setup project, adding it into the target folder. It's better because you see exactly what you're adding, and the destination locations that may be scattered anywhere on the target system (Program Files, Common Files, GAC and so on).
There's no advantage to organizing files into nicely sorted folders on the build system because the setup project doesn't care. If you want the files nicely sorted on the target system you need to create those folders in the File System view on Target machine and add each file to its destination.
When I upload a project from the local machine to the server repository, and try to download it from the server to another machine I am always missing some .dll files and cannot build the project?
It sounds like you're likely keeping externally needed DLLs in your bin folder, which would not be added to (many) source controls by default, as the DLLs in your bin folder get updated after each build.
The not adding bin to source is the correct route, you have a few options on what what you would need to do:
Use nuget packages that get restored automatically during build
add the DLLS to a separate folder (I like to use "extLib" or "3rdParty" as my folder name, and add that to source, referencing the DLLs in the separate folder.
ensure all machines have required DLLs/SDKs installed on the machine
They are listed in (my) order of preference, but that's just my own opinion.
Probably because repo's ignore file is ignoring those file types. Check you .gitignore file in the root of the repo.
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.
I need to generate a list of all the files which are enough to run my application on any machine. I need this for a setup program. When i go to bin/release folder i'm able to see some pdb files and some configuration files, which i think will not be needed. I tried to disable generation of pdb files too but it still generates pdb for the other projects present in the solution.
So i need a way in visual studio 2008, which can get me all the files (the .exe and .dll and other files) required by my application to run.
Thanks.
Have you tried publishing the application (Build > Publish [app])?
This should just copy all the essential files to the specified folder.
The pdb files are used for debugging. Building in "Release" mode should exclude these files.
You can also create a setup project within the solution. Using that project it is possible to see a list of included files.
If you make a release build or publish the application then you should have a complete set of assemblies your application needs.
However, it can still rely on assemblies which reside in the GAC (Global Assembly Cache) of your machine. Check the references of your project if you think there are assemblies missing in the bin folder.
To solve this exact problem with our software, we wrote a simple console app that finds all the .vbproj & .csproj files in our projects directory, then changes all of the to Release mode (which does not create pdb files, documentation files etc).
This is then run by the build machine (CruiseControl.Net) before it starts compiling the projects.
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.