Community Forums
Results 1 to 4 of 4

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

  1. #1
    Join Date
    Jan 2004
    Posts
    131

    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

  2. #2
    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?

  3. #3
    Join Date
    May 2017
    Posts
    3
    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

  4. #4
    Join Date
    Aug 2005
    Posts
    531
    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.
    Cary R.
    Configuration Engineer

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •