I have made a program in VS2010, written in C#. It uses extra libraries and databases.
My teacher wanted to test it a few days ago, so I had sent him the setup file which publishing the project created. This setup didn't work because there were "files missing".
I then just sent him the whole published map.
Which files do I need to include for a published program to install and work on another pc?
It depends on several things. Usually the contents of the bin\debug or bin\release should be sufficient providing your teacher has the same version of .Net installed. One thing it depends greatly on is whether or not you are using any libraries outside the core .Net. If not, then the bin directory should be sufficient. If you are using third party libraries and those libraries are GAC'ed on your machine then VS will not copy them to the bin directories.
This is a very similar question: Dependencies and references - What exactly should I reference?
Related
Currently I'm distributing a software product that includes three merge modules:
Microsoft_VC80_CRT_x86.msm
ATL.msm
policy_8_0_Microsoft_VC80_ATL_x86.msm
Some customers use packaging technology that doesn't like these MSM files (I think because they have technical problems with them writing to WinSxS). Can I just distribute the dll files directly into my application's Program Files folder, and if so which dlls do I need? Is it just atl80.dll?
Your alternative is to run the VC_redist.exe for that version of Visual Studio, run it from the bootstrapper with whatever setup tool you're using.
I don't know what you mean about packaging technology. The only way merge modules (msm files) can be installed is to add them at build time to an MSI file build. In other words, the only packaging technology that's relevant is Windows Installer and MSI files. So you need to find out exactly what this issue is. Everyone uses the merge modules or the VC_redist.exe because it's the only reliable thing to do.
One issue with doing it yourself in an unofficial way is that Windows Update can't find them (and that applies to static linking to). So when Microsoft applies a security fix to those Dlls then you are leaving your customers vulnerable.
This is a problem that has been eating at me for a while, and I just haven't found a good solution (no pun intended) for it.
I'm using Visual Studio 2010 with Subversion and Ankhsvn. It works very well, however, my biggest problem with it is that it only retrieves and manages files that are "included in the project". This is great in many situations, but kind of sucks when you want a folder with objects that you want to include in the solution, but do not want to have in the project itself (in this case a web project).
In this case, I want to include some 3rd party DLL's into source control (so they can be kept up to date when syncronizing with version control). I don't want the developers to have to install the 3rd party dll's seperately. What normally happens is that you reference the DLL's from some other location and they get copied into your bin folder at compile time.
I do not wish to include them in the project because i don't wan them copied to the web server when I publish the site (other than via the bin directory where they should be). I thought of creating a seperate project for these, but that would create a useless dll with no purpose that would then get copied to the bin folder because it's referenced.
I've also tried to check them in from the bin folder, but this has caused a number of problems where files did not syncronize prolerly, with subversion saying things about an already version folder being present etc.. This seems to be a subversion or ankhsvn problem rather than a visual studio one. As such, i try to keep the bin folder untouched by version control.
How have you solved this problem in your projects?
This is how we do it in our project.
We have a SourceCode folder which has the subfolders for the projects which contain the code.
Additionally this has a folder called Library which has the correct version of any 3rd party dll's that we use. This folder in in version control and hence everyone always has the correct version of the 3rd party dll's
All references in the projects to 3rd party dll's are relative from this Library folder.
Since everyone has the SourceCode folder on their machine, it works fine with no issues.
EDIT:
Added image of Solution Folder with library contents to it
I have two web projects, both these projects share client-side JavaScript currently residing as almost identical copies in both projects. I say almost because I'm clearly having versioning problems with these files.
I've managed to put the files in a solution folder and created links to them from my projects and this works when I publish the projects. However, when I run the WebDev server locally these files are not hard file system links? They seem to be maintained within the Visual Studio project as a reference only.
The problem is that the WebDev server will make a request to the presumable valid location of the file but it will not find it there because it doesn't exist as a physical file at that location.
Anyone know how to work around this?
If you use SVN, you could have the files managed as externals. Basically this will allow you to have the shared files maintained in one location, and have an external (physical file) reference to them.
http://svnbook.red-bean.com/en/1.0/ch07s03.html
Dave the Ninja
Here is a post that can help you :
Using Linked Files with Web Application Projects
http://consultingblogs.emc.com/jamesdawson/archive/2008/06/03/using-linked-files-with-web-application-projects.aspx
I checked in a project to SVN with about 15 references from one dev box then checked out the same project on a second dev box but most of the reference files are missing. Is it possible to checkin the reference files automatically?
Version control will only keep track of the actual files underneath the working folder. If the third party libraries are installed elsewhere on the machine, they will not be included in the source control at all.
You'll have to do one of these:
Ensure that the 3rd party libraries (eg, nunit, enterprise libraries) are installed on all required development machines.
Don't install the libraries using the normal installers at all, instead, add the individual dll's and other resources to source control as Vendor Branches, then bring them under your project by either branching them into your project location, or by adding an svn:externals definition.
Copy the required reference files under into your source locations, add them to source control and reference them from there.
I think it's hard for Visual Studio SCC tools to determine wether or not these files should be automatically added. If you're using the first scenario Jim T described, you definitely don't want that to happen.
(I know I am using Visual Source Safe, I do not have a choice because it comes with the MSDN Subscription license and my company does not want to buy a third party source control solution....)
I have a VS 2005 solution with 3 C# class library projects, 2 ASP.NET web site projects and one ASP.NET web service project that is stored in a Visual Source Safe database. Some of the projects reference a common library DLLs that handle common taskes.
When a new person sets ups the solution on their workstation and build it for the first time, it checks out the common library DLLs in the bin folder of the ASP.NET web site and web service projects. When another developer that is currently working on the project tries to build, they receive a "file excludely checked out by other user" message.
VS 2005 does not display the check mark next to the DLL that is causing the headache.
Is there a way to prevent this from happenning?
Why do you have the bin folder checked into SourceSafe? On projects I've worked on, the third party dlls were checked into a separate folder (maybe called ExternalLibraries or ThirdParty) at the same level as the solution file. The compile process would be set up to copy the dlls into the bin folder. This could be handled with .refresh files, or with a pre- or post-build step. This way, VisualStudio/SourceSafe won't see the files as having been updated, and won't try to check them out.
If the compile is already pulling the files in due to them being dependencies, I'd suggest removing the bin folder from VSS. This is not the same as an "Exclude folder from project" which hides the folder from VS05 when compiling (and gives you the compile error you mentioned.)
If the third party dlls aren't going to change, another option is to make those files read-only in VSS. This way, no users will be able to check out the files. (To mark the files read-only, you will need to change the permissions from the VSS management tool; the developer's tool doesn't have that feature.)
As for why it happens, I don't believe VSS checks the binary version numbers - it is only concerned with modify file date. If a new developer pulls all the code out, all files (including binaries) will have the current date as the modify date. This may be causing the unnecessary checkouts.
Regarding your later comments - I'm not sure why VS05 wouldn't see the files as under source control but the VSS UI does. I suspect it has to do with the .vss files (and similar) that are in that folder. In this case, VS05 is incorrect.
Not sure if this is the problem or the best fix, but if you update every developer's machine so that they have the same latest versions of the common DLLs installed, this shouldn't keep happening. I think VSS checks out the DLLs in the \bin folder if the version referenced by the project file doesn't match the version installed on the developer's machine.
#Pedro:
In the VS 2005 IDE inteface, it does not indicated that the \bin folder is in VSS. When I look at the project in the VSS UI, it shows that is checked out to the user who did the latest build on their workstation.
If I use the "Exclude folder from project" option, it will cause the compiler to throw "reference not found" errors.
In my solution structure, the class library project creates a reference to the third party DLLs using the "Add Reference" command. Then I set a project reference to the class librarys in my ASP,NET web site and web service projects (using the web site project template). Because the class library has a dependency on the third party DLLs, they are copyed in the \bin folder.
How do I set a file to read-only through the VSS UI?