In VS2008 I have a setup project which installs the Primary Output of one app to the application folder, and the Primary Output of class library project into a subfolder of the application directory.
Both projects reference several third-party assemblies (some DevExpress UI controls).
When I install the application, the subfolder is successfully created and the class library assembly is correctly put there. However, all the third-party assemblies are duplicated to this folder as well (they are in the main application folder and the subfolder).
One other completely bizarre behavior (IMO) is that if I delete the extra assemblies manually from the subfolder, then I run the executable in the app folder, the deleted assemblies get copied to the subfolder again.
I then modified the setup project to only install the class library assembly from its Debug folder (as opposed to the Primary Output). When I install the app the DevExpress DLLs are still going to both folders. (However, if I delete the extra assemblies and run the executable the extra dependencies do not reappear this time.)
What's going on here? All I want is the class libraries I add to the Setup Project to appear in the subfolder, and the executable and all the dependencies to be in the Application folder.
Whats really driving me batty is I migrated this solution from VS2005 and I never had this problem before. Is there a setting in VS2008 at that causes this?
Related
I have a VS solution with multiple projects, and I'm using Nuget to obtain external references. However, it's important that the package files for one project Not be in the same folder as the packages for the rest of the solution. As such I would like to put them into their own, seperate folder.
It would also be acceptable if all of the packages went into one folder, and then only the ones used by other projects were copied into the folder that they need them to be in. But I don't know of any way to achieve this behavior either.
If it helps, the specific scenario is a Unity project referencing a standard .NET class library project. The solution contains the .csproj file for the library DLL and also the ones generate by Unity. Because unity regenerates those project files every time the Unity project is changed, any packages to be used by those projects need to be inside the Unity project's Assets/ folder, or else the references won't be added to the generated .csproj files.
However, ALL dlls contained anywhere in the Assets/ folder are added to the generated projects, unless manually marked as not to include on a per-file basis. Which is why I don't want the packages referenced by the Library project to end up in that folder, as manually going through and marking every single .dll in every single package not to be used by the Unity project will become very tedious very fast. Especially since some packages download numerous dlls for many different versions of .net.
I have a vs 2010 winforms application that needs to connect to an external device and to do this it requires use of some third part DLLs. These DLLs have been copied to an assemblies folder and referenced from there, and the references has the "Copy Local" property set to true.
My application has been running on my dev machine quite happily and the time has come to create my setup project. However, there's no sign of these DLLs in the Detected Dependencies folder of my setup project, and even though my setup project builds and installs ok, when i try to run the application on a test machine after I've installed it, I get a class type error and when I look in the installation folder, there's no sign of these DLLs.
Could someone give me some clue as to what I need to do to get third party DLLs into my setup project so they install correctly and my installed application can make use of them?
Thanks,
Karl
Im setting up a svn repository and wondering where i should put the dll files.
What Ive currently done is put them in the /bin/debug folder and then link them in my project file in visual studio.
is this the way to do it?
I presume you are asking about third party dll files, because the output (exe/dll) files generated by the project are better left unmanaged by SVN, because they are regenerated on each and every build.
What I usualy do is create a Lib folder, that is on the top level of my source tree, and put all needed references there, usually in additional folder divided by tool or by functionality (logging, emailing, apis, etc, etc...)
You should not put anything from the bin/Debug or bin/Release in your source control. If you do that, you will lose them when you clean your solution or your projects.
What you have to do is create a folder, within the solution folder for example, and reference the dlls in your projects. Any third-party dll that is in the references of a project will be copied to the bin/Debug or bin/Release folder when the project is compiled.
We typically have a seperate folder called dlls or something where we keep all 3rd party dlls/assemblies
Dlls are only needed at runtime. For a quick fix, you may copy your dlls in the Debug folder where your .exe file is. This Debug folder is at the same level as the solution .sln file in Visual Studio. Which thing you will have to do each time you start a new project... Debug folder
A better solution would be to copy all third party dlls, plus all the corresponding .h and .lib files, in 2 folders, say C:\dev\include and C:\dev\lib, and then add these 2 folders to your path environment variable once for all. This way, you'll be able to access them from all your projects, without having to copy them over and over.
Now, if you want someone to be able to run your project on another computer, you'll need to copy all needed .h, .lib and .dll files in your project in a separate folders that you create, say include and lib again, in your project directory where your own program files are, as mentioned in the previous posts. Project folder
PS. Sorry, it would not let me upload the 2 screenshots, so click on links.
I typically put it in a Lib folder within my Visual Studio project solution folder. I would also create sub folders all the way to indicate whether the dll is for a 32 bit or 64 bit build and also which version of Visual Studio was used to build it. So something like this: Lib\WIN32\VC2015\ . Then in the Project Properties of the project, under the Debugging Configuration Property, I set Environment to
PATH=$(SolutionDir)Lib\WIN32\VC2015;%PATH%
By doing this, I can have separate dll folders for different project configurations if I want to and also the dll files are in a good place to check into source control as well.
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 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?