Dependencies discovery issues

[il76]

Hi,

I an having very strange issues with IS LE in VS 2012:
1. In one of the projects dependencies are discovered OK when I start VS, but after some time using it it may start reporting "ISEXP : warning : -6248: Could not find dependent file ..., or one of its dependencies of component ....Primary_output". If I restart VS, this message disappears
2. One of the IS projects reports this -6248 warning on Microsoft.CSharp.dll file
3. I have two WinForms projects in same solutions, when I add one of them to IS project, it works fine. When I add another one, I get lot of -6248 warnings on class library projects in the same solutions and on some 3-rd party assemblies from GAC (these class libs and assemblies from GAC were working fine in first EXE project)
4. Another IS install project produces several -6248 warnings, but resulting installer package contains all needed assemblies, including the ones that were mentioned in warnings.

Questions:
1. WTF is going on?
2. How to fix or at least to diagnose this?

I googled lots of links, but most of them were old and others are unanswered.

[chiranjeevi]

Please refer to the below KB article,which talks about the similar problem and possible resolutions.

http://kb.flexerasoftware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q109065&sliceId=1&docTypeID=DT_ERRDOC_1_1&dialogID=112354397&stateId=0

Thanks~
Chiranjeevi

[il76]

chiranjeevi wrote:
Please refer to the below KB article,which talks about the similar problem and possible resolutions.

http://kb.flexerasoftware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q109065&sliceId=1&docTypeID=DT_ERRDOC_1_1&dialogID=112354397&stateId=0

Thanks~
Chiranjeevi

Hi, Chiranjeevi, thank you for the answer, seems like I was not subscribed to thread automatically and did not noticed your answer. I seen the article you've mentioned and checked all these recommendations.

Make sure the file specified in the warning message is located in the same location as the key file for the Component specified in the warning. When this type of warning occurs, it’s recommended that all files within that Component are located in the same folder on the build machine to eliminate these types of issues.

Yes, all files are there. See my initial issue details - IS nay report missing file until I restart Visual Studio. After restart in some cases (2 of my install projects) it stops reporting issue and build went OK, I even don't need to rebuild solution, so files are the same and were untouched. Also I double checked the folder before restarting Visual Studio and files were there. Also I tried to rebuild solution before restarting Visual Studio, but issue remains.

Make sure all dependent files that were acquired via the Dependency Scanner are actually located in the locations referenced by the setup.

Could you clarify this item? Where locations should be referenced? All files I need are in the same folder as primary output of my EXE project.

Note the files included in the project and make sure the "Modified" column contains an actual date for each file. Additionally, if any files display the message "***File_Not_Found***", re-add them to the project as their locations have changed.

All references are fine, EXE file runs from this folder without issues and can find all required DLLs. I tried to rebuild solution and issue remains. No "File_Not_Found" messages and no broken references in any of my projects in solution.

Make sure that you are able to load the dependent file and that the assemblies are accessible according to the assembly binding rules. An example of a binding rule is the requirement that a dependent assembly be in the same directory as the primary assembly.

EXE file runs from this folder without issues and can find all required DLLs. App.config file does not contain any assembly mappings, so all needed and correct DLLs are there in the same folder.




Any other ideas/suggestions?

[JP_Lee]

I've been having the same problems, and I've been doing quite a bit of looking and not found a solution.

looks like it's been a problem for about 6 monthes judging by this stack overflow question here

Best solution I've come up with is to explicitly add all of your references to your install project (I've got an app that requires about 20 odd DLL dependencies that we've built, so I've added those 20 projects, because I can see no rhyme nor reason why some of them are not included.)

Hell if I know what I'm gonna do if one of our secondary dependencies doesn't get pulled across properly.

[Christopher_Pai]

Dependency scanning is like training wheels on a bicycle. Just take them off and learn how to ride.

[tony12345678910]

Dependency detection in ISLE is a disaster. I tried to turn it off in Options/.NET/ settting scanning to None but it is still picking up a ton of wrong dependencies. Why is it still scanning?

[Christopher_Pai]

Automated dependency scanning and authoring is a bad idea in the first place. InstallShield offers it because their market research indicates that customers wrongly want it. In my experience the scanning should only provide information to base sound engineering decisions on.

Turn it off for all existing components and all future components as explained in my answer to your other thread.

[JP_Lee]

Coming from VS2010 setup projects, that's a loss of functionality.

In VS2010, I could happily add the primary output from my main project in the solution, and VS2010 would happily dependency walk my solution, and build and include all of the required files (including 3rd party components marked copy local) into the setup msi.

If you're saying we shouldn't rely on automated dependency scanning, are you saying that to build a setup project in ISLE, we have to manually walk our dependency tree, and explicitly include each and every file required?

The other option to explicitly add the build output files from VS into the setup project. However, as ISLE uses absolute paths, we'll have to standardise the local source folders between the developers machines, which thinking about it, is annoying, but not much effort to rectify. The real concern, is how we build setups for different build configurations. Unless we can take into account the current build config in the file reference path, we'll have to have a setup project for each build config, which is sub optimal to maintain, and there's no way to debug in the debug msi if the issue is in the release msi.

The third option is to add all of my project outputs to my setup file, but that means my setup project takes about 10 minutes to build, because now all of the included projects go through the cycle of "not being able to find stuff" even though I've explicitly included on those dependencies in the setup project, and makes my VS2012 prone to crash for some unknown reason. I get the box that appears when an unhandled exception bubbles all the way to the top of the application.


Is there another solution that I don't know about, that resolves my concerns?

[tony12345678910]

Christopher, I would do that for each file listed, but the only file listed is the primary output. If I click on Dependencies it says it requires a paid version. I the Files section I do not see the files selected by the scan, which is why it took many hours to figure out it selected the wrong ones (from another solution altogether).

[il76]

Seems like there is no way to make dependency discovery work.

One more question, guys: When I tried to add all dependencies manually and turned off autodisocvery for my promary output build time increased drastically. From about 1 minute to about 5 minutes.

[SwethaRao]

Hello,

Can you also try adding the path of the dependency file to environment variables and check if that helps?

Thanks ~ Swetha

[il76]

SwethaRao wrote:
Hello,

Can you also try adding the path of the dependency file to environment variables and check if that helps?

Thanks ~ Swetha

You mean operating system environment variables?

[SwethaRao]

il76 wrote:
You mean operating system environment variables?

Yes. Please try adding the path to Operating system environment variables and let us know if that worked.

Thanks and Best regards,
Swetha