I have a .NET application debug folder but not the complete visual studio solution. I am trying to generate a wix installer from this.
Things tried:
I created a project called setup using WIX toolset.
In my .net solution, there are now two projects, the main project helloWorld and the wix project setup. Inside the setup I added the reference of helloWorld and it worked fine. I am able to create the installer for my helloWorld project.
Here, I added the reference of the application project for which we want to generate the installer.
Problem:
As I have only application's - debug folder(i.e the application's .exe , .exe.config and other files) and not the complete visual solution. I am not able to generate the WIX installer from it.
Question:
Is it possible to generate WIX installer from debug folder without having the complete visual studio solution?
If possible, are there any document or things I can try?
Redistributing Debug Binaries: Debug versions of binaries should not be redistributed for several reasons (technical, security, legal, practical, etc...).
Technically: First of all, they require their own complement of debug runtime DLLs in order to run and these debug files are not present on normal, non-developer computers with standard runtime components installed. Debug dlls often have an extra "d" in their file name: mfcm140d.dll versus mfcm140.dll for example (look for them on a PC with Visual Studio installed).
Legally: Redistributing debug binaries for standard runtime components is actually illegal - it violates EULAs with regards to what is redistributable (normally). And no, this is not a trifle - don't do it.
Security: Debug binaries also contain a lot of debugging symbols and in .NET assemblies a lot of meta information that should generally not be sent to others. You would have to ask someone else for the full technical details.
Practical: Several practical issues too. For one thing: don't underestimate the confusion involved in redistributing debug versions of files. Creating an internal setup with debug binaries to test on computers set up with debug runtimes could work for internal QA though. Just wait for someone to send that to a customer or for someone to upload it for download on your web-site (by mistake).
For debugging purposes some people redistribute *.pdb files - "Program DataBase" - along with their software - instead of debug dlls. More on PDB files.
Hello WiX: With the above stated, adding debug dlls to a setup is no different from adding release files. There is a WiX Visual Studio Hello World example here. It should show you the basics of compiling a working setup with WiX and Visual Studio. There are also a bunch of quick start tips for WiX here (many links to samples).
Some Links:
install VC++ Debug Runtime Distributable (debugging purposes ONLY)
MFC100d.dll Issue in VS2010
Related
I'm beginning the work of moving an internal class library (.net framework, C#) to a series of nuget .net standard packages, which we will also serve internally. I'm in the research phase.
And I am attempting to research using the VS (2017) debugger and working to create our conventions for where debug versions of the packages (with symbols) will be and where the release versions (without symbols) will be.
I build a small dummy .net standard package in one solution, and have used nuget add to place it in a file share. And I have successfully consumed it in a different solution.
However, when I try to step into the code in the consuming solution, somehow, visual studio is doing something smart and actually stepping me into the source at its ORIGINAL location. Which is fine in some ways of thinking about it, but I want to simulate the situation of a different developer on a different machine consuming the package and not having that original source available, such that the only way to step into packaged code would be to consume a debug version with symbols. But visual studio is foiling me by figuring out the original source location and I don't see how it is doing that.
How can I get VS to be "dumber" so I can simulate on my machine what it would be to consume packages on another machine that didn't have this package source?
Thanks in advance.
How can I get VS to be "dumber" so I can simulate on my machine what it would be to consume packages on another machine that didn't have this package source?
You can try to specify the Symbols of that .net standard project to exclude from automatic loading.
Detail:
As we know:
The Program database (.pdb) files, also called symbol files, map
identifiers and statements in your project's source code to
corresponding identifiers and instructions in compiled apps.
Symbol files also show the location of the source files, and
optionally, the server to retrieve them from.
And the default setting of symbols loading for debugging in Visual Studio is that Load all modules:
That is the reason why Visual Studio smart and actually stepping your into the source at its ORIGINAL location.
So, to resolve this issue, we need to disable Visual Studio "Load all modules", we could specify excluded modules for your .net standard project.
To accomplish this, click the link on that window, then add the name of your .net standard:
Then Visual Studio get to be "dumber", not find the ORIGINAL location.
Hope this helps.
When I build a C# program (this has been going on for several different solutions/projects I have been working on) in Visual Studio 2017, the new, updated code will build and run in debug mode (and run correctly).
However, the application that Visual Studio has been outputting when I build/debug them has been remaining with the original, first version of code that I saved. When I choose the options to rebuild, it will update the time stamp on the application and .pdb files, but the application will perform the way it did in earlier code versions, not the most recent code version that was running problem when I ran debug mode immediately after pressing Ctrl + F5.
These are C# Console Apps with the .NET Framework 4.6.1, if that makes any difference. I checked the output folder, and it is indeed the desired folder and the one I have been looking in... so why is the time stamp updating on the application (.exe file) that it outputs, but not the code itself? What am I missing?
When I run into strange things like this in Visual Studio, the first thing that usually works is to clean the project and rebuild. If that doesn't work, I'll close Visual Studio, re-launch, then clean and rebuild again. If that doesn't work, I would start looking into any extensions you have installed that might be getting in the way of your build process.
Further, you can look into logging the extensions activity to help troubleshoot if there are issue there. See the following article:
https://blogs.msdn.microsoft.com/visualstudio/2010/02/24/troubleshooting-extensions-with-the-activity-log/
You may have already tried this, but since it wasn't mentioned I thought I'd provide it for others in a similar situation.
Two possible reasons:
(1) Your project was not recompiled during debugging. Please enable Edit and Continue under TOOLS->Options->Debugging.
(2) Visual Studio has a concept of incremental build. If you have a solution with two or much more projects and if you change source code in only one of the two projects, the "Build" command will compile only the modified project. But the "Rebuild" command, on the other hand, it will recompile all projects in this solution.
I have four different solutions: two C/C++ libraries, a C++/CLI wrapper which uses those libraries and a WPF project.
How can I debug my libraries when they are called by my WPF Project?
When you want to debug anything you call that is outside your solution, you need to help Visual Studio find the debugger information. If you just link to a library it can run code but you can't do step by step debugging becuse you're only linking binaries and not source code.
For debugging external libraries, you need two things:
link the library files compiled in debug mode
tell Visual Studio where to find the .pdb files (which contain useful information for debugging).
To make sure the .pdb files are loaded correctly, you can go in your project options then Debugging->Symbols and then select the directory where the .pdb files from your library are. Visual Studio will put the .pdb files in the release directory usually (default settings).
Important note: that since you are using a wrapper over the libraries, you need to make sure that the wrapper itself is also doing this (or you will only be able to debug the wrapper).
Recently I started programming in VS2012 C#, a Windows Forms Application and it is almost finished.
I wanted to make a functional and good looking setup wizard
So I searched the internet and stackoverflow and soon it became clear that NSIS is a program that has enough functionality to do the job for me.
In VS2012 I have 3 options: Debug, Release and Publish
Debug - works fine on my computer and my program works but if I want to deploy on other machines I thing I need to reference some *.dll files, icons, help files, etc. which I need to distribute in the setup file (I think).
Release - I think it's almost the same only a different folder.
Publish - Makes the following files for me:
/publish/setup.exe
/publish/PCWS-Report.application
/publish/Application Files/PCWS-Report_1_0_0_0/FastReport.dll.deploy
/publish/Application Files/PCWS-Report_1_0_0_0/FastReport.Bars.dll.deploy
/publish/Application Files/PCWS-Report_1_0_0_0/ODBCMngr.dll.deploy
/publish/Application Files/PCWS-Report_1_0_0_0/Image1.jpg.deploy
/publish/Application Files/PCWS-Report_1_0_0_0/PCWS-Report.application.deploy
/publish/Application Files/PCWS-Report_1_0_0_0/PCWS-Report.exe.manifest
/publish/Application Files/PCWS-Report_1_0_0_0/PCWS-Report.exe.deploy
/publish/Application Files/PCWS-Report_1_0_0_0/PCWS-Report.application
/publish/Application Files/PCWS-Report_1_0_0_0/PCWS-Report.exe.config.deploy
/publish/Application Files/PCWS-Report_1_0_0_0/Resources/
Firebird_ODBC_2.0.1.152_x64.exe.deploy
Finally my questions:
From which directory I take the files to build my Setup Files with?
And if it is the Publish directory, do I need to rename the files?
And do I need all the files, like the .manifest.deploy file or the .config.deploy etc.
In previous releases of Visual Studio (e.g. 2010), you had two built-in options to create an installer of your project
First one is to create Setup or Deployment projects. For Windows Forms Applications this tipically means to build an MSI installer. This is no more an option in VS2012
Second one is called Click Once deployment. It is still supported in VS2012. Note, that when you select Publish option in Build menu in Visual Studio you will produce Click Once deployment files (i.e. .deploy).
NSIS is a totally different choice because it isn't a Microsoft technology but it is developed by Nullsoft (yes, their product is Winamp too). It is a scriptable install system, and is a very good one IMHO.
If you would like to create an NSIS installer you doesn't even need Visual Studio. (Of course you have to build your solution first before you create the installer.) You create an .NSI file manually with your favourite text editor (which can be Notepad++ or even VS itself), and build it with makensis.exe which is part of an NSIS installation.
So to your first question: you always use the files in the Release build folder in production. You should read more about the differences between Debug and Release builds. (E.g. here) In short: you use the Debug build while you develop your application and you use your Release build when you want to deploy your app to the production environment.
I have a C# project that I have created in Visual Studio Express 2010. This program uses a 3rd party C# class that relies on/calls a C++ dll. I just copied the filename.dll into the bin/debug and bin/release folders of the project folder, and the application ran fine.
I am under the assumption that I can copy the release executable for the project to another computer and run it as long as the filename.dll is in the same directory as the executable. However, trying this on another computer with correct frameworks installed, etc. the program crashes with a system.dllnotfoundexception.
Strangely, my friend reports that the program runs on his computer with Visual Studio installed, but not the one without, though I have not actually seen this.
What could be causing this? And how can I get the release executable to run on another machine?
Thanks for any replies!
-Chase
Make sure you have the Visual C++ runtime installed (VS2005,VS2008,VS2010).
If your c++ dll is build by visual studio it may depends on the CRT, two things to check here :
If it depends on the release or debug CRT. Microsoft don't give you the right to distribute the debug version except for debugging purposes so it could be a problem.
Witch version it depends on
The last version from vs2010 could be copied in the same directory as the executable (msvcp100.dll for c++ msvcr100.dll for C)
Previous versions needed to be installed as side-by-side assemblies so running their setup was mandatory (Some versions like the VS2005 one are included in framework install but others like the VS2005 SP1 one need to be installed separately)
In any case the best way to debug such problems is to install Dependency Walker (free) on the computer having problems and let it tell you what dll is missing.
The easiest (albeit maybe not the "best") solution to this problem is adding a Setup project to your solution. A setup project will help you find any dependencies, and make them available during install.
The steps you need to take are the following:
Add a Setup project to your solution (found in Add project.../Setup templates)
Right-click the project, choose "Add/Project output..." and add the startup project of your program.
Right-click the project and choose "View/Custom actions".
Right-click the root node, select "Add Custom Action..." and from "Application Folder" add "Primary output from [your project name here]".
Now when you compile, an .msi installer is created. Run this installer on the other computer, and your program will be installed and runnable. To uninstall, run the installer again, or remove the program from "Add/Remove programs" under Control panel.