cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
cada0310
Pilgrim

EntityFramework.SqlServer.dll missing (only via MSBUILD)

Hi there,

I'm using Visual Studio 2012, with IS 2013 Premier integrated. I have a .NET C# solution which uses entity frameworks, and one of the projects in the solution is a simple IS installer.

When I build the solution in Visual Studio, all is well - when I run the installation I get the entityframework.dll as well as the entityframework.sqlserver.dll laid down by the installer.

However, when I build the solution with MSBUILD, the entityframework.dll is laid down, but not entityframework.sqlserver.dll. I've looked in the build output folder when I run with MSBUILD, and both dlls are sitting in there...it seems more like IS isn't seeing is as a dependency somehow...but only in the MSBUILD case.

Anyone seen anything like this before? Any tips to troubleshoot?

Thanks,

Chris
Labels (1)
0 Kudos
3 Replies

Re: EntityFramework.SqlServer.dll missing (only via MSBUILD)

I have exactly the same problem, as well as it missing several other dependencies when I try to compile from MSBUILD.

VERY annoying! I have spent hours on this. Not an InstallShield fan right now.... something so fundamental as detecting dependencies works in the IDE but not MSBUILD!

Flexera - can you confirm this is a bug?

Is it only in the LE version?

Any simple workaround?
0 Kudos
dan_mclean
Pilgrim

Re: EntityFramework.SqlServer.dll missing (only via MSBUILD)

Has anyone found the solution for this problem? Currently running into this problem and have run out of ideas. Currently happening on InstallShield SAB 2016
0 Kudos
Cary_R
Pilgrim

Re: EntityFramework.SqlServer.dll missing (only via MSBUILD)

To reply to the sentiment here that something as simple or fundamental as dependency scanning should be easy--you'd be surprisingly mistaken. I've had situations where MSBuild itself was copying to the build output location the wrong version of an assembly whereas it worked with the full IDE on my Dev machine. (In this case, the problem was a dependency of a dependency which picked up the wrong version earlier in the build before processing the direct reference).

Are you obfuscating your assemblies? This removes (obfuscates) metadata in the assembly which can trip up dependency scanning. I think there's a whitepaper for including project outputs from Dotfuscator somewhere out there if that's the case... Are you using a primary output? If so, what do the MSBuild logs look like compared to the IDE logs?

My advice when it comes to your installer: don't rely on dependency scanning during your build if possible. Statically link in your application and dependencies to the project file. In the short run it may seem like more work, but you'll be a step ahead in the long run to exercise tight control over what goes into your installer.
0 Kudos