I have developed an app in WPF using VS 2015. I created a release build for this app. But when I copy this build to any other folder outside it starts properly but does not launch API methods i.e. API hitting methods are not being called or my app is not responding. As it runs properly in debug mode I can't find the reason. Can anybody help?
You should to copy ALL dll's from the Release folder. Your exe file is dependent on configuration (yourprogram.exe.config) as well as other assemblies (dll's from your folder). Without these dependencies the application cannot run (because that is how .NET works). All classes and methods are wrapped in dll and if you run your program without some dll, then it means that there are no necessary classes or its methods which worked with other dll's in your Visual Studio.
You can use ILMerge to merge all dependencies into single .exe file to simplify distribution of your application.
More detaiils on ILMerge can be found here: ILMerge on CodeProject
Related
I'm trying to create exe/msi for my solution
it contains the following Projects
ActiveDirectoryEngine: library used to implement AD operations
ADService: windows service - performs the work in the background
CryptographyEngine: library used to encrypt/decrypt data
TerranovaActiveDirectoryHost: Dashboars/win form to manage/check the service's status
SyncToolSetup: the setup project "it only targets TerranovaActiveDirectoryHost"
Here is the contents of the Setup project:
I tried the same steps for different Solution, with ONLY one windows forms application, and it worked fine, but it looks that it doesn't work when I have more than one referenced projects.
The install and Uninstall options are not enabled
Update:
all the previous projects are referenced in the Win forms project, so am I targeting the right one when creating the exe/msi?
The only project with the Install option is the setup project. Other projects in the solution do not have install option just because there is a setup project as part of the solution.
References in a non-setup project (such as a C# build) are not automatically included in a setup project. References used to build code are not necessarily things that need installing on the target system. The setup will try to help with dependencies, but it's unreliable, and only a guide. For example, your Application Folder view contains some files that are part of the .NET Framework, and you definitely don't install them because they are installed as part of the standard .NET framework install.
The setup project must be told what needs to be installed on the target system. There are generally two ways of doing this:
Selecting project output as input to the setup project. This can be rather indeterminate because it's not always obvious what files are included, or what to do if the files need installing to different locations.
Add the files that you know you need one at a time by adding them in the File System view of the directory they need installing into. Typically, executables go into the Application Folder (defaults to Program Files..), data files to User's Application Data, shared files to Common Files folder, some assemblies to the GAC and so on.
I have two separate projects/solutions. One is an ASP.NET web app and the other is a console app that runs as a WebJob on Azure. These two separate projects/solutions share some common projects' DLLs.
We work on these shared projects through the web project's solution in Visual Studio and when done, I copy and paste the DLL's into the bin folder of the console app.
When I compile the console app, I notice that the shared DLL's revert back to a previous version. I know this because I see the Date Modified dates of those shared DLL's. The moment I compile the console app, they go back to previous versions.
Why is this happening and how do I prevent it?
You definitely should not drop assemblies into output folder by hand as they will be overwritten from whatever location build takes them from. If you have to do it manually - copy files over original location. To debug - enable verbose logging for build and carefully check where assemblies are copied from.
Automated solution integrated with the build is better approach.
Standard solution for sharing assemblies between project is NuGet. As most basic solution you can just use file share to drop packages. Check out guidance for continuous integration build system you are using as there is probably recommended nuget source (i.e. package feed in VSTS).
In my VS2012 project I use a third party dll. I do not add it into project references, but I have added its path into environment system variables (in Path), as suggested into the user manual of the third party software.
So inside my project I don't have any references to that dll, but only a .cs file where there are some [DllImport("xxx.dll")].
In the same solution, I've created an InstallShield project, to create a setup for my application. When I run the setup, I notice that the dll is copied into my application folder. That is not good for me, because if I try to run my application I have some compatibility problem with other dlls of the third party software.
If I remove manually the xxx.dll from my application folder, it works correctly.
So, how can I avoid that xxx.dll is copied inside the application folder?
Turn off any of the "magic" options so that you can control exactly what files you install. For example, set.NET Scan at Build to Properties instead of Dependencies and Properties.
I have a WPF application that is going to be installed on several client PCs. I'm using InstallShield Express Edition as the deployment tool for that.
I've created a different project(DLL) to keep track of the software installations. Basically is a stand-alone C# project that reads, writes and does some validation checking in the Windows Registries, and can be integrated in other WPF applications (this project/DLL is going to be useful for other Apps).
What I want to do is to create an .EXE file to register the installation. This .EXE is not used in the main WPF application, but uses the .DLL that I've just talked about above.
I've managed to do that by creating a different solution with a single Console Application project, and referencing the necessary DLL's.
But what I really want is to create it as project within my Main App Solution, and when I do that no .EXE file is generated other than the Main App executable.
Is there anything I can do to get the 2 .EXE files (Main App and InstallationRegistration) or is the way I'm currently using the only way?
This is more a nuisance than a problem, but still... it will be a better way to keep track of this small module in all the different Applications I've developed.
Thanks
Are you saying the Console EXE is not created as part of the build/run of the solution?
Or the Console EXE is not created as part of the InstallShield deployment project?
If you are referring to building Console EXE as part of the build/run of the solution:
Generally, when you hit F5, Visual Studio builds only those projects you designate as Startup and their dependencies.
You will have to explicitly build that Console App or the Entire Solution.
You can designate it as one of your Startup projects if you want it to be built everytime you hit F5; or specify it as a dependency of the MainApp project (that's a bit of a cheat but it gets the job done).
After trying for a few different ways I got to that DUH!!! moment.
What happened is that VS was creating both .EXE files for the Main App and the Console Application, only with each one is in their respective Debug/Release Folder
For Example:
Main App -> C:\Projects\MyApp\MyAppUI\bin\Debug\MyAppUI.exe
Intallation Control.EXE -> C:\Projects\MyApp\InstControl\bin\Debug\InstControl.exe
NOTE: C:\Projects\MyApp is the solution folder.
It kinda makes sense they are on their own folder, but on the other hand, there should be an option in VS to choose where we want to send all the solution's .EXE
Hope it helps someone in the future.
By default, all intermediate compilation artifacts are placed in the obj folder under a given project in the solution (so far I am not aware this can be changed).
For project outputs they are, by default, put under bin\Debug or bin\Release depending on your Build Configuration.
This can however be changed from the Project's Properties; specifically the Build tab has an "Output path" option for you to specify the build output location.
This has to be done on a per project basis but I generally create a SolutionDir\bin folder under the Solution root and direct all project output paths to SolutionDir\bin\Debug or SolutionDir\bin\Release as the case may be. This has the added advantage or reducing the total size of SolutionDir by avoiding multiple copies of output assemblies in large solutions with complex interdependencies between projects.
Does this help?
My C# code loads a C++ DLL. It works fine on my PC, where Visual Studio 2008 is installed. But on other machines the program stop with an exception
Unhandeled exception: system.dllnotfoundexception unable to load dll ...
this application has failed becasue the application configuration is incorrect....
How can I make this code run on a machine that doesn't have VS 2008 installed?
You must distribute your DLL along with your project if it is a custom DLL of yours. If not, you must install the required DLL either with a custom installer or if it is from a different provider, a installer of them.
This post might be a bit older, but
DLL Files And .NET ClickOnce Deployment
I want to deploy one of my .NET apps as a ClickOnce application. The issue is that I am connecting to Oracle (see previous posts here and here). Connecting to Oracle requires at least, 4 DLL files that generally have to be in the same directory as the EXE file. The issue is that when the program is published, the DLLs are not referenced in any way, so the program won’t work.
Then I read about adding the files to the project, so that ClickOnce and the Publish processor will figure out that the DLLs are required and add them to the manifest.
Here is the process in Visual Studio 2005:
1. Put the 4 DLL files in their own directory in your solution directory (for ease of use mostly).
2. Add all four files to your project by going to “Project->Add Existing Item…”
3. Click on each DLL file in the solution explorer and then change their property: “Copy To Output Directory” to “Copy Always”.
That’s it! Now when I publish or even run the application I don’t have to worry about if the DLL files are where they should be.
in vs 2008 on project:
Properties>c/c++ >Runtime Library > choose: Multi-threaded Debug (/MTd)