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
Related
I am trying to distribute a program in our small business environment. I tried to choose therefore ClickOnce in Visual Studio 2019 and DotNet 5. However, if I open the EXE from the published folder, it tells me that a DLL is missing. After adding this one, it tells me another DLL is missing, aso. In contrast, if I publish to a local folder, everything works as expected.
What may I do wrong? It seems like the missing DLLs have something to do with PowerShell automatization (Microsoft.Management.Infrastructure) which as I understood is only available as either x64 or x86. I tried to restrict my program to x64, however, without any success.
If you know any other simple distribution method for a small business (all pcs conneted locally) I am very happy and thankfully.
The solution was simple. Missing dependencies can be added here, during the setup for ClickOnce export creation.
We are moving to VS2010 and TFS from VS2008.
Presently we have a solution that has a dozen or so projects that are built into DLLs and then put in the GAC as well as 3 website projects in this solution that are built that use these DLLs that are put into the GAC.
In VS2008 we have post build events that use gacutil to register them and this all worked great on local developer machines however it doesn't work with TFS and the Build agents. I had to remove this post build event.
The issue now is the websites won't build because the DLLs are not in the GAC on the build machine where the agent is doing the building.
I tried referenceing the projects in VS2010 from the websites but this simiply removes the assembly references from the web.configs and then copies the dlls to the bin folder when it's built/published which is not what we want.
These DLLs will be in the GAC in production and the 3 websites all use them so we don't want them in the BIN folders.
We have third party DLLs as well that will go in the GAC that are used in all 3 websites as well.
What is the proper way to get this to work in VS2010 and TFS?
Installing the DLLs into the GAC can be a real pain with version management and deployment. Try creating a "Lib" folder to keep all the third party DLLs. We do this in our work and works fine. This won't be a problem with XCopy deployment as well.
See help with TFS and referenced DLLs for more details.
To register a DLL into the GAC you need admin level privileges, which is by default not the case of you Team Build Service account. That's the reason why it fails.
You have then two choices:
Put admin privileges to the Build Account for you GACTUtil to succeed.
Change your Visual Studio projects that reference the DLLs that were supposed to be in the GAC to a specific location you'll deploy them (e.g a ThirdParties folder for third parties DLL, and another one for your own DLLs) in debug/testing configurations, keep the GAC reference in release.
Some people will tell you that 1. sucks because you're not supposed to give admin level to the account, because it's bad.
Some people will tell you that 2. sucks because things get over complicated and that you won't test things the way they actually ship.
My advice is go for 1. because:
- It's easy to do
- You don't break your current architecture
- Admin level to the service won't be that bad a risk, really...
How can I manually add the SQLite Entity Framework 4.0 provider without using the installer setup so that the Visual Studio New EDMX wizard will be able to use it to create a new data model?
I'm not sure which provider you are using, but I am asuming you are using the System.Data.SQLite provider available from http://system.data.sqlite.org/
In order to use the Design Time support in Visual Studio, you must download the installer and install everything. This will setup the Design Time support and also install the System.Data.SQLite and System.Data.SQLite.Linq assemblies into your development machine's Global Assembly Cache.
For your application to access the SQLite database, you will need to add a reference to those two assemblies to your project.
To do this, right click on the project and select "Add Reference". If you ran the installer, the two assemblies will be in the list. If you can't find them, download the assembly files from the website, put them anywhere on your drive and reference them by selecting the file.
To distribute your application, you simply need to send along the assembly files. The easiest way to do this is to put the two dll files in the installation folder.
You can do this by right clicking on the reference in the visual studio Solution Explorer, and selecting Properties. Here, set Copy Local to True. Now when your application compiles, a copy of the SQlite assemblies will be put in your target directory.
If you are deploying the files manually, simply copy along the assembly files and keep them in the same folder as your executable. If you are using One-Click Deployment or any other kind of Deployment, make sure the assemblies are deployed together with your application.
Note that, as far as I know, the assembly version used by the Design Time support must be the same version as the one deployed by your application. So if you update the one, make sure you update the other as well.
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?
(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?