I learned how to make an installation package through this tutorial, but I encountered a problem.
https://learn.microsoft.com/en-us/cpp/ide/walkthrough-deploying-your-program-cpp?view=vs-2019#install-the-visual-studio-setup-and-deployment-project-template
I made the installation package strictly according to the tutorial. After clicking Primary Output, all the DLL files I needed appeared in the list on the right, but after I Build Solution, the names of the DLL files in the list were all cleared, and I got the installation package There is no DLL file either.
I found that when I added Project Output, the DLLs all appeared in the DetectedDependencies directory. Is there any problem?At this time I choose to generate the project, these DLL libraries will disappear, and the installation package does not contain any of them
enter image description here
I solved this problem. I added the files manually and added the DLLs I needed one by one to complete the packaging. When I click the Primary Output button, the DLL list automatically generated by the system seems to be invalid. Just ignore it. This may be a BUG
Related
I'm evaluating TFS Build 2013 for use in a corporate environment.
TFs itself has been running fine for ages, and today I setup the Build components. No problem so far.
I grabbed a fairly simple project from source and created a manually triggered build definition, using the standard defaults.
I ran a test build and hit an issue straight away with a primary reference. The error in the logs is:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "XYZ.dll".
So a bit of back of background on how we store and use references:
We create a root folder for the solution, inside this goes the .sln file and sub directories for the projects as normal. We then add a "References" folder at this level, which holds all of the DLLs required for the project. These are generally DLLs from other in house code libraries, but also certain 3rd party ones (such as the old Enterprise Library DLLs, and anything else we don't get from NuGet).
Each of the projects that require these DLLs reference this folder (and from inspecting the .proj files I can see the link is stored as "..\References\XYZ.dll" etc. This works fine for local builds and nobody has ever had an issue. The reference folder gets checked into TFS and everybody gets a copy. From what I've read through trying to diagnose our issue, this is a fairly common and accepted way to manage references.
So, the build error that I receive is as above. Basically saying the build target can't find the DLL from the References folder. The log goes on to list all of the places it's tried to find it.
Crucially (it would seem) the first line reads:
For SearchPath "{HintPathFromItem}".
Considered "..\References\XYZ.dll", but it didn't exist.
Furthermore it looks in the Framework folder, various default assembly folders, the GAC and so on, none of which (of course) contains it.
So I'm wondering where I've gone wrong. Have I misconfigured one of the build/drop locations? Is there some other convention for referencing required DLLs (bearing in mind our entire company uses the "..\References" folder setup, or is there something else?
I'm fairly new to TFS Build, but I'm by no means new to TFS or Visual Studio
itself. I've spent about an hour or so Googling without finding anyone experiencing the same issue as me, so any help would be greatly appreciated.
Thanks
UPDATE:
The build agent is configured as follows:
Build Agent- working directory:
D:\BuildAgent\$(BuildAgentId)\$(BuildDefinitionPath)
The build definition "Source Settings" have the (I assume) default values of:
Status: Active | Source Control Folder: $/ProjectRoot | Build Agent Folder: $(SourceDir)
Status: Cloaked | Source Control Folder: $/ProjectRoot/Drops | Build Agent Folder:
The references folder is not explicitly configured here, but when I look in the Build Agent's working directory I can see it:
D:\BuildAgent\1\ClientName\SolutionName\src\Dev\Evolution\Source\SolutionName.Solution\References
If I open VS2013 Command Prompt, navigate to the folder that contains the .sln file (and also the References folder) and run "msbuild d:\path\to\Solution.sln" then it builds successfully with no warnings or errors.
Well it turns out this wasn't a fault with TFS at all...
The problematic DLL, although present in the References folder, was not actually checked into TFS.
Right clicking the References folder in VS (added as a "Solution Folder") and selecting to Add Existing Item, then a check in fixed the issue.
So the References folder was being used as you would expect, in the same way that VS uses it. MSBuild worked locally because I had the file in my local folder, but because it wasn't part of the solution it wasn't with the rest of the source.
I've got a TFS project with a NuGet package installed, and it references an assembly from that package. However, another copy of the same file is in a folder in the tree, and it is somehow overriding the reference and being used instead.
Even if I remove the reference entirely and manually point it to the correct path, the other file still is recognized and overrides the path.
Actual Case:
Correct Reference Path:
c:\Stratigen\Stratigen\packages\MonoGame.Binaries.3.2.0\build\net40\MonoGame.Framework.dll
Overriding Reference Path:
c:\Stratigen\Stratigen\Stratigen\Tools\MonoGame.Framework.dll
The file in "Tools" needs to be there because it is a build against SharpDX (API wrapper for DirectX) and is used to compile shaders for multiple versions of MonoGame, while the game should be running against the OpenGL version (unless I were to purposefully change something).
The especially odd thing about this is that I've had this file in the "Tools" folder this entire time, and for weeks never encountered this issue, yet now it's got this odd behavior.
It seems that having included the "Tools" directory in the project was to blame. This folder is already handled by TFS but since there are a few source files in there (for the shaders) I'd included the folder. However, this for some reason gave priority to the DLLs there over those from the packages. I'm going to re-add the source files but not the DLLs/EXEs from that folder and it should work fine then.
So I see two solutions to my current problem, but I was wondering what the pros and cons are, or if there is a defacto best practices approach.
So my current project has a number of configuration files, help files, and other external content. I need this content local to run and debug the application. Currently we duplicate this content in a standard windows installer project. This clearly is a bad idea. We are moving to a new setup that uses the WiX installer, and I'm currently setting the project up next to the code project and trying to figure the best way to share resources. I see two solutions.
One is that I can put all the resources in the WiX project and then add them as links in the code project. This way I know what I'm debugging is installer.
The other option would be to leave the content in the code project and path into it in the installer using the reference variables.
Right now it seems 6 one way, half dozen the other. Any persuasive arguments for either method?
Assuming that these configuration and help files are going to be installed in the same directory as the executables then definitely put them in the code project, mark them as Content, and add a reference to the code project to the installer project. If you're using WiX 3.5 the files will be automatically included in the installer along with the executables, which makes writing simple installers much easier.
For earlier versions of WiX or more complex deployment scenarios (where the content files could be going into different directories) you would still put them in the code project but then you'd use File elements with a relative path or reference variable in the Source attribute to include the the content files from the code project directory.
I don't believe that putting the content files in the WiX installer project directory instead of the code project directory will do anything to ensure that the version you use to debug will be the same as the version installed. That can only be ensured by thinking through the process of how your application finds these content files and making sure the right versions are found.
So going back to the simple case where the content is in the code project and marked as Content, and it will be installed and loaded from the same directory as the executables, then it is only a matter of setting "Copy to Output Directory" to "Copy always" or "Copy if newer" and then you can be sure the versions used in debugging and the version installed will match.
I have a Web Setup project in VS. I'll be switching to WiX, but that's in the future and currently I need to solve the following issue.
I need to exclude some common dlls from the project. So I build the project, VS updates the list of Detected Dependencies. I exclude them and the setup builds. I check the file list with Orca and the files are not included in the installer.
But when I clean my output directory, reload the solution and do the build, some of the dependencies do not show as excluded! And so they end up in the MSI. (This is what is happening on the build machine).
I think that the problem might be with the fact that these are second-level dependencies:
my app -> NHibernate.dll -> Antlr3.Runtime.dll
(Antlr dll ends up in the MSI).
Is this a bug or am I missing something?
I found this page on msdn that has a work-around for the Exclude flag being reset to False:
Previously excluded files are included again when the solution is re-opened
When you exclude a file from a Setup project, you may see that the file is included again after you close and re-open the solution. This may occur if there are two copies of the same DLL file from two different source locations.
To work around this error, change the Copy Local property on one of the files:
In Solution Explorer, click on the DLL reference that you want to remove.
On the View menu, click Properties Window.
Change the Copy Local property to False.
This installer project was created back in 2004 and upgraded ever since.
There are two offending dll files, which produce a total of 4 errors.
I have searched online for this warning message and did not find a permanent fix (I did manage to make it go away once until I have done something like a clean, or built in Release, and then in Debug).
I also tried cleaning, and then refreshing the dependencies. The duplicated entries are still in there.
I also did not find a good explanation for what this error means.
Additional warnings are of this nature:
Warning 36 The version of the .NET
Framework launch condition '.NET
Framework 4' does not match the
selected .NET Framework bootstrapper
package. Update the .NET Framework
launch condition to match the version
of the .NET Framework selected in the
Prerequisites Dialog Box.
So, where is this prerequisites box? I want to make both things agree on .Net 4.0, just having a hard time locating both of them.
I assume you are having more then one primary project outputs added to your installer. Furthermore these projects use the DLLs that generate the warnings, you can exclude them easily but as you observed this is not a permanent fix. In my solution I got rid of these warnings permanently by right clicking on the project outputs (that reference the DLLs) and defining an exclude filter (just use the name of the DLL). I do this on all project outputs that reference the DLL. As a final step I add the DLL manually to the installer (this requires the DLL to be in some well defined location (e.g. a lib folder). This way the DLL gets added only once and you got rid of the warning.
Right click on the setup project file, selecting Properties will show a little dialog that has a Prerequisites... button: That answers your second question I guess.
If you right click on your solution in the Solution Explorer window, you'll see an option for 'Project Dependencies...'
Clicking that option displays a dialog that allows you to set the dependencies between the various components of your solution. Then, if you have the 'Project Start' option set properly (which component in your solution is the startup or primary component), you only need to include the 'Primary Output' of your startup project in the installer, and it will pickup the dependencies and include the DLLs only once in your setup installer. Set all of that up, clean your solution, rebuild, and then build your installer.