TFS Build / MSBuild not including scanned dependency DLLs.

[jcoone]

Greetings,

I am using the InstallShiled LE Spring 2012 version.

I have several projects that are using some Third party controls. In order to use these controls we add some file references for a set of assemblies registered in the GAC, these references are added to the Main Exe project for the solution. These are registered as part of an SDK developer package.

When I build the Solution in Visual Studio 2012, the installer includes these registered files and the installed application will work without any issues. However, if I build the Solution through the MSBuild command line or through the TFS Build Process (which relies on MSBuild) these third part DLLs are not present and that causes the application to fail when installed with an installer created by this process.

I have tried running MSBuild on the same machine that can successfully build the installer in VS2012, and on the TFS Build Server as well as running it through the standard TFS 2012 build process.

It basically looks like builds within VS2012 run the .Net Dependency scan, and the others do not.


Does anyone know why this does not work? And more importantly, how to fix it?

[jcoone]

Update on this continuing issue.


Even if the DLLs are referenced directly from a file location by the Project, they are not included in a command line or TFS build unless the ones in the GAC are uninstalled. The framework has to be installed in order to register the license for build usage, so uninstalling the framework is not an option.

Using hard coded paths in the Installshield project for these references is also not an option since each Build Definition that uses them stores the source code repository in its own pathing structure and that pathing will be different from the developer machines.

For some reason the msbuild command line build for isproj files seems to be failing to include any DLL that is referenced by a project and is also registered in the GAC.

[jcoone]

Another update:


I have figured out how to get Verbose logging for the ISProj build process when it is done on the command line, but it appears that the Visual Studio IDE is not using the Installshield.targets file, so the property is not honored for the verbose logging. Changing the logging verbosity in the Tools-> Options in VS does not affect the isproj log output in any way that I can find, it only increases the verbosity for the other projects in the solution. I was hoping to compare the more verbose logs between the build processes, but since I cannot generate a more verbose log for the VS Build of the isproj file there is nothing to compare to.

[chiranjeevi]

Hello,

Could you please kindly provide us a reproducible sample project to investigate the issue further?

Regards,
Chiranjeevi

[jcoone]

I tried at first with just creating a test dll for referencing, but that did not exhibit the behavior.

This project includes some references to 3rd party DLLs for some custom WPF controls, we have the control set installed and the DLLs are registered in the GAC, but even after uninstalling the control set we see the same behavior.

I am building under the Release|Any CPU platform/ configuration, with a SingleImage type for the isproj, no setup.exe generated, just the MSI.



I cannot upload the Zip files, The uploader keeps telling me the files are too large. I have stripped out as much as I possibly can and the ZIP file for the solution with references is still 2.6MB in size. The build output zip is 3.9 MB in size.

According to the uploader, both of those should be well under the limit for zip files, so I don't know why I cannot upload them.

[chiranjeevi]

Hello,

Kindly, check your private messages for ftp location details, to which you can upload the required files.

Please let me know if you have any issues accessing the ftp portal.

Regards,
Chiranjeevi

[jcoone]

ok, the test project has been uploaded to the FTP site. let me know if there are any issues with it.


I also uploaded the MSI files output by the two build processes on my maching.

[chiranjeevi]

Hello,

unfortunately I didn't see any files uploaded in ftp location, could you kindly re upload the same project file in .zip format?

Regards
Chiranjeevi

[jcoone]

I am not sure what is going on, I can upload the files and according to the FTP command line responses they are uploaded but they do not show in a listing of the directory contents.

So I have no way of verifying the files successfully uploaded. the two files are BuildOutputs.zip and InstallshieldReferenceTest.zip

[chiranjeevi]

Hello,

Thank you for the response.

We have received the the files you have uploaded to our ftp location and currently we are working with our engineering team on this issue.

As soon as we get further information on this, will keep you posted with the updates.

Regards,
Chiranjeevi

[jcoone]

Has there been any progress on this?

The release notes for IS LE 2013 had information that made it look like this was fixed, but it is still an occurring issue.

[chiranjeevi]

Hello,

Please refer below msdn forum thread which discusses the same issue.

http://social.msdn.microsoft.com/Forums/vstudio/en-US/11b700d9-9d9b-4977-993c-af44ce5ed91d/tfs-build-msbuild-not-including-scanned-dependency-dlls-for-project-primary-output-in?forum=tfsbuild

Hope this helps.

Regards,
Chiranjeevi

[jcoone]

The thread did not help at all, especially since I was the one that started it at the same time I originally posted this thread here. At the end of that thread I was directed to post in the MSBuild forums, and at the end of the thread that I posted in the MSBuild forums they directed me to Flexera due to the InstallShield LE being a "3rd party software" and not part of the MSBuild System.

[Chaitra]

Hi,

We are currently working with our engineering team on this issue and we shall keep you updated on this at the earliest.

Thank you for your understanding and patience.

Thanks,
Chaitra

[jcoone]

just wanted to follow up and see if any progress has been made regarding this issue.

I have managed a workaround, but it required the editing of the MSBuild Target files. Essentially I am forcing it to include all "Copy Local" dependencies into the Primary outputs for the project.

Doing it this way feels very hacked together and prone to errors, also the target files have to be edited for each versions of the framework used and in both 32 and 64 bit versions.

I have maintained copies of the unmodified target files as a precaution, and for now this appears to be working but I would like to see a more permanent solution found.


James Coone

[david_jost]

Hello,

We are in 2016... I'm using InstallShield 2015 LE for Visual Studio 2015 with TFS 2015 update 3 and I always encounter the same problem!

Would it be possible to get an answer/solution from Flexera?!

Best regards,
David

[asmk20]

I am also facing this same error. The files being added in dependent files list is different in manual build and msbuild installshield build.

[NameTooShort]

I know they've fixed some bugs related to this, but can anyone provide a simple sample that can display this behavior?

[JohnTech]

The below is for general discussion use to narrow down the issue and is not directed at any particular individual.

Is this issue seen when dependencies are explicitly included in the project as well ? or just when scanning for dependencies at build time?
The best practice is to explicitly include the files needed for a release to work.

Under some circumstances your build process may include a difference (different files) from one build machine compared to another build machine. For example computer A builds setup 1 with n-number of files and computer B builds setup with a different number of files. This discrepancy is determined after build when examining the built MSI database.

When you are relying on file dependencies to include files in the InstallShield project it is possible the missing file(s) are not registered on the build client. When dependencies are marked for inclusion based on being a dependency within an InstallShield project the file(s) are expected to be written to memory. As a result the build process includes the file(s) in the build as you expect. If the file does not exist (physically) or is prohibited from being read into memory during build you may get less than expected results.

During the handling of dependencies if the main assembly has a dependency and the file is not there to be consumed at build there is no error thrown. Therefore it is important to include the files needed in your project explicitly.

- John