locked
Access remote DLLs: Change devenv.exe.config but solution dependent (loadFromRemoteSources) RRS feed

  • Question

  • Hi,

    I have to reference in my Silverlight4 Solution in Visual Studio 2010 some DLLs that are located on a network folder.

    For security reasons Silverlight prohibits this by default. I get the error message

    Warning 1 Could not load the assembly file://myShare/myDLL.dll. 
    This assembly may have been downloaded from the Web. If an assembly has been downloaded from the Web, it is flagged by Windows as being a Web file,
    even if it resides on the local computer. This may prevent it from being used in your project. You can change this designation by changing the file properties.
    Only unblock assemblies that you trust. See http://go.microsoft.com/fwlink/?LinkId=179545 for more information.

    It seems as if the DLLs are still "unblocked".

    In order to remove this error message I could add the statement <loadFromRemoteSources enabled="true" /> to the runtime tag of the devenv.exe.config, which would be fine because I trust the share drive.

    Now my question is

    1. Is there a better way to do this?
    2. There are several developers working on this (and other) projects. I do not want to bother them with this issue. I am looking for a possibility to allow embedding the DLLs from remote locations without changing on eachs developers PC the devenv.exe.config manually.
    • Could I define the command <loadFromRemoteSources enabled="true" /> in the *.sln or csproj file? (which would then be part of the source code control)
    • Should I check in the devenv.exe.config with my changes into the source control and additonally a batch file that replaces the orig. file with my modified one and starts the studio aferwards? The batchfile I could check in as well and every developer has to load the solution via this batch file?
    • Somehow Similar approach like above: Is it possible to start devenv.exe with a parameter (e.g. something like -loadFromRemoteSources) that tells the studio this special setting?
    • Or could I use a something like a set variable where I would overwrite the devenv.exe.config settings, e.g. batch file: 1) set loadFromRemoteSources = true 2) start devenv.exe mySolution

    Any idea?

    Thanks,

    Peter

    Wednesday, May 18, 2011 7:30 AM

Answers

  • I don't see any good reason for referencing the assembly from shared drive. Let's say you have two teams. One team is working on framework and other team is using that framework to develop the apps. In that case, I would suggest you to have the Continuous integrartion setup for two teams and do the auto-copy the daily build of framework and push it to other team's version control.. 

    Wednesday, May 25, 2011 3:13 AM
  • The advantage of using build server is that other developers doesn't need to do any extra things like mapping drive and saying that location is the trust one or etc.. 

    Normally, Framework team used to have two env such as dev and staging.. CI will build the framework with staging environment at the end of every day or every week. once it finished building, it will copy those assemblies to other team's resposition.. 

    Main Respository 

    ----- Framework

    -----------Source

    -----------Dev Env Build

    -----------Staging Env Build  (auto-copy the assembly to App\LIB\Framework after build. )

    ----- App

    ----------LIB

    --------------Framework

    ------Source

    I'm not sure why you think that it's not a good idea.. Do you see any weak point with this apporach? 

    Wednesday, May 25, 2011 11:30 PM

All replies

  • If it is possible to load the dll to a server, it will be easier to get access to dll and download it

    http://www.michaelsnow.com/2010/05/06/silverlight-tip-of-the-day-14-dynamically-loading-a-control-from-a-dll-on-a-server/

    Monday, May 23, 2011 12:04 PM
  • Thanks, interesting tutorial.

    But unfortunately in my case it won't be possible to store the DLLs on a web server. And as far as I understood your article it is not possible to configure such an ClientAccessPolicy.xml for network share folders?

    From my point of view it would be best if I could add the parameter <loadFromRemoteSources enabled="true" /> as a kind of command line argument when executing the devenv.exe


    Wednesday, May 25, 2011 3:01 AM
  • I don't see any good reason for referencing the assembly from shared drive. Let's say you have two teams. One team is working on framework and other team is using that framework to develop the apps. In that case, I would suggest you to have the Continuous integrartion setup for two teams and do the auto-copy the daily build of framework and push it to other team's version control.. 

    Wednesday, May 25, 2011 3:13 AM
  • Hi,

    The project setup is somehow similar to your assumption, but I can only access the DLLs (that's another longer story). I still can't believe that there is no simple solution for this issue.


    The batch file mentioned above seems not to be a good idea as well, because I do not know how to realize this on our build server. So for me, defining a parameter when starting devenv.exe would still be the best approach.

    By the way: My *.csproj file looks as follows:

    <Reference Include="myRefDll">
          <HintPath>\\myShareFolder\myRefDll.dll</HintPath>
    </Reference>
      Is this correct or would e.g. an additional parameter help to accept the path?

    Wednesday, May 25, 2011 8:18 AM
  • The advantage of using build server is that other developers doesn't need to do any extra things like mapping drive and saying that location is the trust one or etc.. 

    Normally, Framework team used to have two env such as dev and staging.. CI will build the framework with staging environment at the end of every day or every week. once it finished building, it will copy those assemblies to other team's resposition.. 

    Main Respository 

    ----- Framework

    -----------Source

    -----------Dev Env Build

    -----------Staging Env Build  (auto-copy the assembly to App\LIB\Framework after build. )

    ----- App

    ----------LIB

    --------------Framework

    ------Source

    I'm not sure why you think that it's not a good idea.. Do you see any weak point with this apporach? 

    Wednesday, May 25, 2011 11:30 PM