I am using Microsoft.Build.BuildEngine.Engine to build a WPF application. This has been working successfully for class libraries and web applications, but now trying to use it to build a WPF application I am getting the following error:
Target MarkupCompilePass1:
c:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.WinFX.targets(294,9):
error MC1000: Unknown build error,
'API restriction: The assembly
'file:///C:\Program Files
(x86)\Reference
Assemblies\Microsoft\Framework\v3.0\PresentationCore.dll'
has already loaded from a different
location. It cannot be loaded from a
new location within the same
appdomain.' Done building target
"MarkupCompilePass1" in project
"TestWindowsApplication.csproj" --
FAILED.
This application builds fine when building using VisualStudio 2008 (i.e. build from the menu), but using the Microsoft.Build.BuildEngine.Engine it throws this build error. Anyone know what is going on here?
I had the same problem and found this on msdn which says
By default, markup compilation runs in
the same AppDomain as the MSBuild
engine. This provides us significant
performance gains. This behavior can
be toggled with the
AlwaysCompileMarkupFilesInSeparateDomain
property. The latter one has the
advantage of unloading all reference
assemblies by unloading the separate
AppDomain.
So since the exception thrown stated that PresentationCore was loaded in the same AppDomain I switched this property using:
projectToBuild.SetProperty("AlwaysCompileMarkupFilesInSeparateDomain", "True");
Which seemed to be the key.
I hope this helps.
Now that is interesting! Check out this issue I hit last week. Same exception and error message, and related to WPF.
If you have a look at the comments for the MSBuild MarkupCompilePass1 task throwing the exception, it may be a clue as to why it's working inside VS2008 but not from your MSBuild process:
<!--
When performing an intellisense compile, we don't want to abort the compile if
MarkupCompilePass1 fails. This would prevent the list of files from being handed
off to the compiler, thereby breaking all intellisense. For intellisense compiles
we set ContinueOnError to true. The property defined here is used as the value
for ContinueOnError on the MarkupCompilePass1 task.
-->
Related
So, i'm taking over a old project that uses nmodbus (and old version at that, 2.0_1.11.0.0, we decided it was best to not update). Nmodbus uses log4net for logging messages. I need to be able to view the logged messages, but it seems like log4net doesnt like WPF, or being in not-main-project.
Adding
[assembly: log4net.Config.XmlConfigurator(ConfigFile = "log4net.config")]
To the Nmodbus project AssemplyInfo.cs file gives me this error:
Severity Code Description Project File Line Suppression State
Error Unknown build error, 'Cannot resolve dependency to assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.' OptimalProdTest
Adding log4net, with NuGet Package Manager, to the main (WPF) project causes Nmodbus to stop working. (maybe has something to do with log4net being an older version in the old nmodbus project, and adding with NuGet will download the newest? Can i somehow add log4net from the other project into the main project without NuGet?)
I found other people with similiar problem who said i should add:
FileInfo configFileInfo = new FileInfo("log4net.config");
log4net.Config.XmlConfigurator.ConfigureAndWatch(configFileInfo);
to "the entry point of your library setup your logger", one guy said, another said "in the constructor of the wrapper class". However, i do not know what files these guys are talking about, nor do i know which project they meant (add to main project or nmodbus?).
( https://social.msdn.microsoft.com/Forums/vstudio/en-US/0c5d7fbb-94a3-4221-ab91-9732c5acee58/cannot-resolve-dependency-to-assembly-because-it-has-not-been-preloaded )
I'm lost and i can't find much help when googling. Anyone has any idea what i should do to be able to view the logs from log4net in nmodbus?
i am running DNN 06.02.X. I design a custom module that needs to upload file to server and i want to use Ajax File Upload control(From AjaxControlToolKit 4.1.60919). for this purpose i Add AjaxControlToolkit.dll to my project reference and must change my project target framework from .Net 3.5 to .Net 4. ok?
my question is: when i debug my module and run dnn (in localhost) get bellow error:
Server Error in '/Mydnn' Application.
Could not load file or assembly 'AjaxControlToolkit' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.BadImageFormatException: Could not load file or assembly 'AjaxControlToolkit' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Assembly Load Trace: The following information can be helpful to determine why the assembly 'AjaxControlToolkit' could not be loaded.
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
You should configure your DotNetNuke website to also run on .NET 4.0 by changing the target framework in the Application Pool in IIS
I solved this problem , for more information see Ben's comment at http://support.dotnetnuke.com/issue/ViewIssue.aspx?ID=21667&PROJID=2
When I launch my WPF application and when it goes to InitializeComponent function call of one user control, it silently quits and only leaves one message in the output window saying Managed (v4.0.30319)' has exited with code -1073740771 (0xc000041d). When I say "silently", I mean there is no exception is caught even if I wrap this InitializeComponent call with a try-catch block (that's how I normally find where the problem is)
Here is what I did: in this application project we need to use a reference Microsoft.Office.Interop.Owc.dll, with version number 10.0.4504.0. Since it is an interop library, when I added this reference in VS2012, it automatically sets the property Embedded Interop Types as true, which I assume means it will not keep an individual dll in the output folder but instead embed this library into the main output (at least this is how it seems in our other references, for example, Microsoft.Office.Interop.Outlook.dll). However, when I launch the project, it throws an XamlParseException saying:
"Could not load file or assembly 'Microsoft.Office.Interop.Owc, Version=10.0.4504.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system
cannot find the file specified.":"Microsoft.Office.Interop.Owc, Version=10.0.4504.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35""
It seems that the reference was not embedded(or the version is not currect. But I verified that the reference version is indeed 10.0.4504.0)
Next I copied this dll directly to the output folder bin\Debug\, to make sure that it can find this library. This time the exception is not thrown, but the whole application just silently quits as I described in the beginning. I tried to google the code -1073740771 (0xc000041d) but there is no article about it. I tried to set the Embedded Interop Types to true/false but the problem is the same.
UPDATE:
I'd like to add more description here. As mentioned above, the problematic library is OWC(Office Web Component)10. I followed this link to make OWC work with VB.NET desktop application: HOW TO: Handle Events for the Office Web Components in Visual Studio .NET. But this official article is so old so I had to make a lot of changes to compile the wrapper dll(mainly because of namespace mismatch). Then when I add the reference to the actual interop library Microsoft.Office.Interop.Owc, if I follow the default setting and let the Embedded Interop Types as True, at runtime it will complain (throw a XamlParseException) that the assembly cannot be loaded (see description above). What the hell? I thought make it as "embedded" would guarantee this library will be found. Then I copy this dll to the output folder, then I have this silently quit problem. But it might be worth mentioning that this time the output window shows the Microsoft.Office.Interop.Owc.dll is indeed loaded. Actually it is the last message before the managed has exited message. So it must still relate to this library.
All of this only happens with OWC10. There is actually a similar way to do that in OWC11(the latest, but unfortunately still pretty old version since it came with Office2003): HOW TO: Handle Events for the Office 2003 Web Components in Visual Studio .NET. But it actually works and the control is displayed on my application. It is because of some other reason that I wanted to try OWC10 instead of OWC11
When I launch my WPF application and when it goes to InitializeComponent function call of one user >control, it silently quits and only leaves one message in the output window saying Managed
(v4.0.30319)' has exited with code -1073740771 (0xc000041d). When I say "silently", I mean there is >no exception is caught even if I wrap this InitializeComponent call with a try-catch block (that's >how I normally find where the problem is)
Next I copied this dll directly to the output folder bin\Debug\, to make sure that it can find this >library. This time the exception is not thrown, but the whole application just silently quits as I >described in the beginning. I tried to google the code -1073740771 (0xc000041d) but there is no >article about it. I tried to set the Embedded Interop Types to true/false but the problem is the >same.
I had exactly the same thing happening to me today, "has exited with code -1073740771 (0xc000041d)." (This happened in both a VB and C# .NET WinForms application for me). I tried debugging and saw I never even got into the Form_Load code block.
I "solved" this in the end by running visual studio as an administrator (and then just opening & building and running the project via the menu).
This is a win8 security issue and it isn't well explained anywhere.
(I got distracted and just opened up a specific project straight out of my task bar/solution file which caused this to happen to me).
You've probably found this out by yourself by now, hope you didn't lose any hair over it :)
Just pointing this out for other people who might have this error occuring somewhere.
Also had this issue, the 'silent' exit with code -1073740771 (0xc000041d) on x64 platforms, on x86 platforms everything was OK.
Part of my application is unmanaged C++, another part is C#. It turned out that my C++ code was not completely ready for the x64 platform. The following change fixed the issue in my case:
// before
g_OrigWndProc = reinterpret_cast<WNDPROC>(::SetWindowLongPtr(hWnd, GWLP_WNDPROC,
reinterpret_cast<LONG>(WindowProc)));
// fixed version
g_OrigWndProc = reinterpret_cast<WNDPROC>(::SetWindowLongPtr(hWnd, GWLP_WNDPROC,
reinterpret_cast<LONG_PTR>(WindowProc)));
So, the generic recommendation is to verify that your code is completely ready for the x64 platform.
I'm attempting to use Dotfuscator 4.7.1000 to obfuscate a Silverlight library that is strongly named. When I attempt to do so, I get the following error message:
External type not found
System.Data.Services.Client.LoadCompletedEventArgs,System.Data.Services.Client,
Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
I have tried adding this assembly to the GAC, and have tried adding user defined assembly load paths to the configuration to locations where this assembly is located to no avail.
I then tried adding System.Data.Services.Client to the input assemblies and ran it again. This time it gets further, but ultimately I get:
Warning: Password protected Strong Name files are not supported
sn returned 1.
It appears as though it is attempting to run sn.exe on System.Data.Services.Client.dll with my local key. I've tried excluding this assembly from any obfuscation tasks, but it continues to do so.
Is there something I'm missing when trying to obfuscate this library? Is there some other way to directly point it to the DLL it can't seem to find that I don't know about? Or can I include the DLL in the project without it trying to obfuscate the Silverlight library?
And for the moment, please no suggestions on alternate obfuscators. My company has a license for Dotfuscator and I'd like to get this running using that. Thanks!
Somehow I must have been screwing up my user defined assembly load paths. As soon as I re-added the path to the Silverlight 4.0 client DLLs everything worked without having to reference System.Data.Services.Client.
I've got a WPF app that runs perfectly fine inside VS.NET, but if I try to run it outside of VS.NET, I get a "... has encountered a problem and needs to close.." dialog. This happens in Debug and Release modes. Why is this happening?
Most likely this is an uncaught exception. You might want to try using the Application.DispatcherUnhandledException Event to display a message box with the exception to narrow down the problem:
Add this to your App.xaml as an attribute to the <Application> tag:
DispatcherUnhandledException="Application_DispatcherUnhandledException"
while the implementation of that handler might look like the following:
private void Application_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
System.Windows.MessageBox.Show(e.Exception.ToString());
}
But without much context this could be anything that is causing it and you probably have a better understanding where it comes from when looking at the exception.
Make sure that you have all libraries that your executable requires to run in the same folder as the executable, as well as any necessary configuration files or manifest files.
Have you already attempted to run the application straight from the debug/release folders? Are all of your references marked as "Copy to output directory"?
Another thing to check is that your project file is not configured to add a parameter to your application.