I have a main project A, with multiple subprojects. Among these subprojects, the project B includes Dlls which are required for the applicatioin to run. So I can select these Dlls and set them to be copied after the generation, which works fine.
The problem is, these Dlls are NOT copied when I deploy my project. How can I put these Dlls in the system32/ folder of the destination computer on deployment?
Working on Windows XP with Visual Studio 2008 SP1.
The application will only be installed on XPs.
Simplest way preferred.
Thanks a lot.
Related
I have a Setup Project for my winforms application. After installing the application using the generated .msi i navigate to the installation folder and try to run the .exe file and nothing happens. I don't get an error or anything.
Steps i've tried to solve my problem.
Making sure the target platform x86 matches in the main project, setup project and every other project in the solution that the application has a dependency on.
In the setup project, made sure that i have a project output in the application folder that references the primary output from the main project. And that the dlls i use also are listed there.
Ran the application as administrator.
Activated Click Once security settings in the main project.
Ran sfc /scannow without finding any issues.
Restarted my computer.
When installing the program using the generated .msi on another computer i have the same issue.
When running the program from visual studion it works perfectly fine.
It is likely that your application is crashing because of some missing dependency.
Possible reasons:
A missing assembly (say, for eg, is all your third party dependencies present in the application folder after the installation ?)
Difference between .Net framework versions between your machine and the installed machine (say, for eg. 4.7 vs 4.7.2)
One useful tool that has helped us in the past is to use the Windows Event Viewer. If the program is indeed crashing, it is likely to have details about the reason for crash.
You can then use it as a starting point for further investigation.
I am using Visual Studio and Windows environment.
The situation is like this:
On the first environment "A" I am building the application.
In bin directory of that project I have my own dll.
Same dll, but different version (old version with an error in code) I have in GAC of this environment.
So running this application on that environment would produce an error because my application would use this dll from GAC, so old dll, bugged version.
The question is what would be if I build this application on the first environment "A" (with wrong dll in GAC) and test this application on the second environment "B" where there is no dll in GAC.
Would Visual Studio take dll from GAC or from dll while building the project ?
If the question is not clear please ask the question.
Regards
I have a console application built in visual studio 2010.
When I actually build the project I am getting .exe file under \bin\Debug\MyProj.exe.
When I Paste and run this .exe from other location it is expecting other files too.
Any thoughts how can I make this as Stand alone exe file.
There should be other DLL's in the Debug library. You need those to run your exe.
If there are no DLL's there, make sure you set the 'Copy local' property of the required references to True, and build again.
If you want to make a standalone program, you should create a new Setup project in your solution. Include the Primary Output from your application project, and the setup should include the required DLL's automatically. Once you build the setup project, you can install your application as a standalone software.
You usually distribute application with bunch of DLLs, that's nothing bad.
But if you really want to make it a single exe, you can look here - same question is answered Embed .net dll in c# .exe . (Valid if your DLLs are also .Net assemblies)
Edit: If you need to easily distribute app to not-very-computer-friendly users, consider also trying ClickOnce. It's roughly something like Java Web start - only disadvantage is that you can't get "Windows Logo" certificate from Microsoft for projects distributed that way.
I don't have Visual Studio 2010 to experiment with, but in Visual Studio 2019 this worked:
Project Properties->Configuration Properties->Advanced->Use of MFC->Use MFC in a Static Library
I believe that I am dealing with some DLL hell.
I have a reference to Microsoft.TeamFoundations.VersionControl.Client in my application and 'copy local' is set to true. The application runs as expected on my development machine.
When I deploy this application I get an exception when trying to execute Microsoft.TeamFoundations.VersionControl.Client.DownloadFile()
Method not found: 'System.IO.Stream Microsoft.TeamFoundation.VersionControl.Client.Item.DownloadFile()'.
The version that gets deployed to my bin directory is version 9.0.3. The method exists. I noticed that a previous version of this dll does live in
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies
How come my application does not appear to be using the assembly that I referenced within my solution and ends up in bin? How can I force this to happen?
Thanks!
I'm not sure if this is it, when I was trying to use TFS 2008, I had to target the x86 processor instead of Any CPU in the project settings. Without doing that, I was finding wierdness when my app deployed to other peoples machines.
Also, I deploy a number of dll's with my app, maybe you've missed deploying something that VersionControl.Client.dll depends on, and it's trying to use another dll of which it's getting the wrong version. I distribute the following (not sure if they're all needed, but you could try distributing more to see if that solved it):
Microsoft.Build.Framework.dll
Microsoft.TeamFoundation.Build.Client.dll
Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Collaboration.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Common.Library.dll
Microsoft.TeamFoundation.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
Microsoft.TeamFoundation.VersionControl.Common.dll
Microsoft.TeamFoundation.VersionControl.Controls.dll
Microsoft.TeamFoundation.WorkItemTracking.Controls.dll
Microsoft.VisualStudio.TeamFoundation.Client.dll
Microsoft.VisualStudio.TeamFoundation.dll
Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.dll
It appears from this link Microsoft.TeamFoundation.VersionControl.Client.Item.DownloadFile() is missing that there are other (and presumably safer) way to do this with other methods.
The application insisted on referencing these dlls from the GAC. I ended up installing VS 2010 on the development environment and referencing the Microsoft.TeamFoundation dlls from the GAC. VS 2010 installed version 10 of the Team Foundation dlls into the development GAC.
I'm building an exe file using Microsoft Visual C# and I've installed Microsoft Chart Controls as an add-on. But whenever I try to run the exe on a different computer, it won't even open and it just crashes. I've tried creating the exe using both 2008 and 2010 editions. The problem is that the other computer doesn't have Microsoft Chart Controls installed, because once I install it, the exe runs fine. However I want to be deploying just the exe file to other people who won't necessarily have Microsoft Chart Controls installed. Is there any way around this?
In Visual studio open up your Solution explorer and expand the references folder. Under this folder you will see the 3rd party DLL references, on any non .net references select them and under the properties set the Copy Local to true. when you setup your deployment make sure that those DLL's are packaged/sent to the target machine. The application is crashing because the remote computer is missing the references it needs to execute your application. It works on your machine because the installer for the 3rd party plugin set up your environment to be able to run this.