InstallShield LE (with Visual Studio 2012) completely fails to detect dependencies

Question

I'm having a nightmare trying to get a simple installer working in InstallShield LE (the one shipped with VS 2012). There are all kinds of problems that I can work around (like the fact I can no longer do "Rebuild All" without it messing everything up - I need to simply unload the InstallShield project during development). But the biggie is that when I build my installer, it includes the wrong version of various DLLs (including both those that are part of my project, and 3rd-party ones like the Entity Framework DLL).

Doing a "Clean Solution" didn't even fix the problem with the DLLs that are in my solution. It was finding a random version somewhere on my machine (in some sort compiler temp directory), and insisting on including that. I eventually fixed that by doing a search in Windows Explorer and deleting every single file it found, but I worry that next time I do a release it'll still manage to pick the wrong file.

Plus, I need to have both the .NET 4 and .NET 4.5 versions of Entity Framework on my machine, and it's picking the wrong one to go into my installer. I can't delete the one I don't want it to include.

What an absolutely shoddy product. I could "upgrade" to the full version to see if that fixes any of these problems, but my recent experience with the LE version puts me off ever using any of their products ever again.

Has anyone else had similar problems? Did you find a solution?

Baskett

Yep. It's adding old versions of dependent dlls that I can't even find on my PC. Am I being punked? – Profligate

Bring back VS Installer - visualstudio.uservoice.com/forums/121579-visual-studio/… – Profligate

What I do is install a fresh copy of Windows on a Virtual machine and test there. – Generality

The only thing that has ever worked for me is to manually include the outputs for projects that aren't coming across. The strangest thing to me is, it started out just fine, worked for months, then without changing the installer, suddenly an it's including old dlls, so I fixed it by including the project output. Then it works for a while, then another project's dlls start showing up outdated... Installer never changed. – Deathbed

On top of THAT, I've built a setup project for a web app twice in a row and had two different .msi files come out - one was correct, the other put all the dlls in the root folder instead of the /bin.. shoddy is giving ISLE too much credit – Deathbed

I have the same problem. anyone find the fix? – Denunciate

InstallShield LE is a joke, the paid versions are overpriced POS – Scarper

I'm seeing all these same issues with the latest version "InstallShield 2015 Limited Edition for Visual Studio". Awful experience, truly awful. – Bianca

Answer 1

Old post so perhaps this can help you or others going through this infuriating issue (assuming you're going through errors like -6225).

Symptoms:

• you can (re)build each project without a hitch, including the Install Shield project
• however, if you build the Solution (of multiple projects) errors just seem to pop up

Try:

• in VS 2012, right click your Solution and select Project Build Order
• even if the order "looks" right, continue to set dependencies
  • e.g. your install project depends on the source project (obviously, but since this tool doesn't "know" it needs some help).

I'm not sure if this solves the "wrong dlls" issue (I haven't gone through that pain...) but the suggestion to check on the project outputs could help....the above did fix my issues.

Yes, I agree, if it can't even do parity with VS2010 and below setup and deployment projects ease of use, then its one of those yet-another-learning-curve that devs have to deal with (waste of time). Not prepared to call it shoddy though, it does have some nice(r) candy - even the "limited" version.....

Anyway I hope this helps....

Update 1

Yes, I can officially call ISLE shoddy indeed. I am now horribly experiencing the "missing dlls" (forget wrong dlls, they're not even in the intall folder, excuse the colorful langauge but WTF??!!) issue. ISLE cannot identify the proper dependencies - and I don't agree with the previous answer. This issue DID NOT exist with the built-in Setup and Deployment Project we've had since VS 2005.

Agreed on comment regarding bonehead MS move.

Once I fix this issue, I'll update.

Update 2

My fix (if there is a better way, please provide answer).. All this is done in the ISLE UI:

1. Scan for dependencies - right click project primary output, select Dependencies from scan at build

2. You will see the dependencies you will have to manually add, indicated by a red icon
   I unchecked them so I could get rid of the -6248 warning which is really odd because IMHO it should be a fatal error in the build - How can this install/setup possibly work if it's missing dependencies?? A warning continues the build, yet it will never work!

3. Then (yes) manually add the dependencies you identified above...

BTW, unsure if this matters - I started the whole process by importing a VS 2010 install project using ISLE (ISLE menu -> Visual Studio Deployment Project Import Wizard). I'm not sure if this actually matters - re: would it still be able to Dependencies from scan at build if you started from scratch (instead of importing)?

So much for "progress" in Setup and Deployment for VS2012...

Hope this helps!

Poynter

2013 beta version fixes this problem. – Quennie

@BalthaZar - you mean VS 2013 and the ISLE add-in in it? Or does VS 2013 revive Setup and deployment projects natively (as an option, not killing off ISLE)? – Poynter

I meant InstallShield LE 2013 version which is in beta state and can be downloaded free from flexerasoftware. – Quennie

Answer 2

I have recently been experiencing the problem you describe: a console application builds correctly, with up to date versions of dependencies in the bin directory, but when packaged with InstallShield LE, uses old versions of the dependency DLLs.

As you say:

Doing a "Clean Solution" didn't even fix the problem with the DLLs that are in my solution. It was finding a random version somewhere on my machine (in some sort compiler temp directory), and insisting on including that.

In my case, the offending files were located in the ASP.NET dynamic compilation cache at C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root and C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root

Clearing the contents of these directories resolved the problem.

As an aside, I thought about adding a build action to empty these directories automatically, but I couldn't do this automatically without falling fowl of ownership permissions.

Jordans

Answer 3

Each setup tool has its problems. Please note that there are no tools which can accurately detect your application dependencies. The best a tool can do is make suggestions. This is why most setup developers determine the dependencies themselves and manually include them in the installer.

If you're not happy with InstallShield, you can try a different setup tool: http://en.wikipedia.org/wiki/List_of_installation_software

The free version of Advanced Installer includes a Visual Studio setup project which may help.

Cupp

Thanks, I'll take a look at those others. It's hard to accept your statement that "there are no tools which can accurately detect your application dependencies". The old Visual Studio 2010 setup projects used to work just fine. Let me be clear: my solution is made up of several projects, which are dependent on each other. The InstallShield installer failed to get the correct version of the DLLs for the projects within my solution, which I still think is ridiculous. What makes it all the more laughable is that all the required DLLs are in the bin folder after a build - why not look there?!! – Baskett

Not acceptable. VS Installer 2005/2008/2010 worked fine for our projects for years. Also, the ISLE migration wizard is horrible. Missing huge chunks of VS 2010 installer package settings and getting error 1001 during install. MS really dropped the ball on this one. – Profligate

Have to agree. The only way I have been able to stymie a VS2015 (now) installer project is when a component vendor released several newer assemblies with OLDER file version numbers. Seems the only way around that snafu is to buy InstallShield Professional at $2799 plus $1300 for support (prices as of the date of this post). – Foil

Answer 4

Instead of using installation shield you can publish your project by just doing right click on project and Publish wizard create exe as Single Image or whatever your selection And finally It take care of all dependency..So when install exe created by Publish Wizard than it automatically install all dependency such .net framework and If some runtime framework required by your application than it will alert you to install that one.

You can have look at this

http://msdn.microsoft.com/en-IN/library/31kztyey.aspx

Imprisonment

That's fine for an EXE, but doesn't help much with (for example) VSTO add-ins, etc. where there needs to be DLL registration and suchlike. – Baskett

Answer 5

I was having a problem with my DLL. It was grabbing a much older one from somewhere. Nothing was in the GAC for this DLL. I tried everything. Finally, I just added the darn thing manually (ISLE) in the Files section by right clicking and selecting add. I found the DLL in my \obj\Release folder. Then I just built the Release again (SingleImage) and everything worked correctly.

Falstaffian

Answer 6

You can fix build order problems (like when you try to rebuild the solution) by right clicking on the solution -> Project dependencies -> Select your setup project and check the projects it uses. (Tested in VS2013)

I expected the InstallShield project to set those dependencies automatically when you select its source files, but apparently it does not.

Cygnus