Home Dashboard Directory Help

WPF Project on a network share with clr-namespace by yoshi666


 as Postponed Help for as Postponed

Sign in
to vote
Type: Bug
ID: 568464
Opened: 6/17/2010 7:46:39 AM
Access Restriction: Public
User(s) can reproduce this bug


Here is my code:
    Title="MainWindow" Height="350" Width="525">
        <Button Height="54" HorizontalAlignment="Left" Margin="58,45,0,0" Name="Button1" VerticalAlignment="Top" Width="144" DataContext="{Binding}" Content="{x:Static res:Strings.cmdButton}"/>

When this project is on my local harddisk it works, but when its on a network share, then
the follow error is shown in the error list:
Error    1    Unable to load the metadata for assembly 'MulitLanguageTest'. This assembly may have been downloaded from the web. See http://go.microsoft.com/fwlink/?LinkId=179545. The following error was encountered during load: Could not load file or assembly 'MulitLanguageTest' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)    M:\MulitLanguageTest\MainWindow.xaml    1    1    MulitLanguageTest

And on the designer window the follow message is shown:
Problem Loading The document contains errors that must be fixed before the designer can be loaded. Reload the designer after you have fixed the errors.

The problem is on this line:
I need this line, that i can localise (over the resx files) the language of my button.

Sign in to post a comment.
Posted by mpurcell-de on 4/18/2012 at 10:03 AM
I can also reproduce this issue, and in an enterprise environment with a large number of constantly evolving references, it is not reasonable to keep a stale copy of a referenced assembly on my local machine. I have performed the work around as shown, however I think given the duration for which this bug has been present, a proper solution should have been developed and adopted by now.
Posted by Karl-Michael Beck on 9/13/2011 at 1:01 AM
I'm receiving the same error but the workaround does not seem to work.

The project is on the local harddisk of a server-machine i'm connecting to using remote desktop.

The problem appeared "out of nothing" - it used to work for half an year until last week.
Posted by Shawn Eary on 5/16/2011 at 8:34 PM
The posted workaround doesn't seem like a good idea to me. There should be a way to specify in the loadFromRemoteSources tag which URLs/Domains will be allowed to load assemblies with FULL trust. Here is an example of how I think the workaround should work:

     <loadFromRemoteSources enabled="true" "https://my.company.com" />
     <loadFromRemoteSources enabled="true" "https://192.168.0.*" />
     <loadFromRemoteSources enabled="false" "*" />

So that any asseblies from my.company.com or IP 192.168.0.* will be loaded with full trust, but assemblies from all other locations will be given very little trust.


Posted by Microsoft on 4/14/2011 at 1:58 PM
Hi all,

Thank you for reporting this issue. This is a known issue and we are actively working on correcting it in the next release of Visual Studio. However, in the meantime there is a workaround as Toni07 mentioned. Please keep in mind that this is not a supported workaround as it bypasses security for all of Visual Studio (not just the WPF and Silverlight designer). To allow projects to load from remote sources, ddit the devenv config file found at (usually found at C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config). Within the <runtime> tag, add the following line:
<loadFromRemoteSources enabled="true" />
Now restart VS and you should be able to load any assembly, bypassing all CLR loading security.

~Jeff Ferman
Program Manager, Visual Studio WPF & SL Designer
Jeffrey.Ferman <at> microsoft<dot>com
Posted by WilkoSki on 3/12/2011 at 2:34 PM
Same problem here. I spent hours looking through my WPF reference book just incase I'd missed something in the Xaml. Then I came across this post.

Come on MS network drives are a fact of life and it should not take 6 months to repro or fix this issue. I suggest you add a test case for future releases.
Posted by D. Schmid on 11/22/2010 at 6:50 AM
In a highly networked environment which is standard about everywhere today this issue should not exist in the first place. Thanks for fixing this *before* you release Visual Studio 2012.
Posted by tlvranas on 10/12/2010 at 7:43 PM
I do all my development on network drives (NAS) so I can access my projects from my desktop or laptop. There is less of a chance of loosing my NAS then the drive on my computer. All this additional "security" is only getting in the way and making what should be a very simple task, create a new project, and run take hours to research for a solution.
Posted by Eugene Ivanchenko on 9/2/2010 at 4:28 AM
This problem is also reproducing in projects which is under Team Suite source control.
But It can be fixed by suggested workaround.
Posted by Marcel Wicke on 8/18/2010 at 6:05 AM
Me and my colleagues at work can reproduce this error as well. But it's no option for us to store our projects or parts of it to a local drive. As long as this bug isn't fixed the WPF-Designer in VS2010 is useless for us in most cases. So please fix it!

Btw. the german error message looks like this (just in case other germans are searching the web for it):

Die Metadaten für die Assembly "..." konnten nicht geladen werden. Möglicherweise wurde diese Assembly aus dem Web heruntergeladen. Siehe http://go.microsoft.com/fwlink/?LinkId=179545. Fehler: Die Datei oder Assembly "..." oder eine Abhängigkeit davon wurde nicht gefunden. Der Vorgang wird nicht unterstützt. (Ausnahme von HRESULT: 0x80131515)
Posted by brian_holley on 7/9/2010 at 11:19 PM
I can reproduce this as well. Adding the XML namespace declaration to clr-namespace causes the XAML designer to fail to load. The project builds fine, but the designer stops working. The exact same solution, when loaded locally, works just fine.
Posted by Microsoft on 6/17/2010 at 10:20 PM
Thanks for your feedback.

We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.
These specialized experts will follow-up with your issue.
Posted by Microsoft on 6/17/2010 at 5:03 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by Toni07 on 7/27/2010 at 7:52 AM
i have found a solution, works for my issues. http://msdn.microsoft.com/en-us/library/dd409252.aspx
File Name Submitted By Submitted On File Size  
MulitLanguageTest.zip 6/17/2010 153 KB