Background info
I'm maintaining a Winforms application in C# using VS2010. The main form has a TabControl with a few tabs. The startup object is a class with a Main funcion (nothing new here) that does nothing more than firing the main form.
The form creates a Datastore object that gets it's connection string to the DB server from a static Settings class. This class has a static intializer block:
static Settings()
{
IniReader reader = new IniReader("config.ini");
//...
}
The configuration file resides in the main project folder (same as the startup object) (and also in the bin and debug folders).
Problem
In solution explorer, when I double click the main form to open it in the designer, VS crashes with the exception mentioned in the title of this question, but also with an error stating that it can't find the config.ini file in "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE".
The problem can be resolved by copying the config file to that location, but I don't find this a real solution.
Why would VS search for the file in that location?
Strangely, the last time I opened the solution, I didn't have this problem. I haven't installed new Windows updates since then.
Remark
The architecture of the application and other design decisions aren't mine. I'm just extending the program and while doing this, I'm trying to improve on the architecture. But that's not the subject of this question.
I think you already understand that the VS designer creates an instance of the form it's trying to show, and that means it will invoke the constructor and any static constructor.
The most common pattern I've seen for avoiding this kind of problem is to move any non-trivial initialisation logic into a separate Initialise method. In there, and in any method other than a constructor, you can use...
if (!DesignMode)
{
//your code here
}
...around any code that isn't actually needed for the form to render correctly in the designer. I realise that means some refactoring of the code and you may not want to do that, but I have used this approach and it avoids this kind of problem well.
Related
I am currently faced with a dilemma in regards to adding any kind of DLL to a ColdFusion project. I have done a ton of research but nothing seems to be simplistic enough to grasp an understanding. I have a Winform that uses the same DLL in the Reference which makes life easy. When looking to add the same DLLs to a ColdFusion project, it doesn't seem to be working. I have tried using the following:
<cfobject type="com" name="myObj" assembly="C:\DocViewer\AxInterop.SHDocVw.dll">
Here is the error message I am receiving as well:
Attribute validation error for tag CFOBJECT. It has an invalid
attribute combination: assembly,name,type.
This site has been very helpful in the past and I am hoping to learn how this DLL in CF9 works so that I do not have to completely rewrite an entire program when the current one works perfectly.
From comments
I tried adding the DLL using the regsvr32 but here is my error now:
the module was loaded but the entry-point dllregisterserver was not found
Well it looks to me like you're using the cfobject attributes for a .NET object instead of for a COM object. The cfobject tag is one of those tags where the attributes vary by action/type, like cfcontent, cffile and cfdirectory (and a bunch of others that don't immediately spring to mind).
So you need the documentation for accessing COM objects specifically, which for the latest version of Adobe's CFML engine is located here: https://wikidocs.adobe.com/wiki/display/coldfusionen/cfobject%3A+COM+object
There's a typo on the docs page, but it looks like this should work for you (although I'll admit it's been a while since I've invoked a COM object):
<cfobject
type = "com"
class = "path.to.com.Class"
name = "myObj"
action = "create|connect">
It looks like you would use action="connect" if you have it installed as a Windows Service, or create if you want CF to instantiate the DLL, but I would guess having it installed as a service would be easier. I'm just guessing, but I think "path.to.com.Class" would be the name of the service if you're using it that way, or it would be the logical path to the .dll file if the CF server is instantiating it. If neither of those options work, then there might either be a version incompatibility if this is being moved to a newer OS, or the service might be misconfigured.
The error message from registering the DLL sounds like (and I'm guessing because I've never created a windows service DLL) it's looking for a specific class or function in the DLL in order to register it as a service in Windows and it can't find that "entry point" in the DLL (i.e. in the same way that Java will look for a "public static void Main(String args)" as the entry-point to a Java program). That may be necessary for a Service, but it's probably not necessary for a generic DLL that might be accessed and used in some other way, so it's possible this DLL might work, but not be compatible with Service registration.
So going back to your sample code, this might work:
<cfobject type="com" name="myObj" action="create"
class="C:\DocViewer\AxInterop.SHDocVw.dll">
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'd like to run a custom EXE against my XAML Resource Dictionaries. Let's say this exe that I've got is going to strip out comments, whitespace and unused resources. The original XAML files need to be untouched, but the XAML (silverlight) and BAML (wpf) that ends up in the XAPs and DLLs needs to be transformed. It needs to work on my computer and the build server.
My question is: what's the simplest and most reliable way to run this exe?
My first thought was to have a pre-build event. But this would have to work on the original XAML file. Development would become quite painful.
By the time the post build event has been run, my resources are already compiled into the dlls.
What are my options?
You should implement the "exe" as an MSbuild Task.
Essentially you build a C# class that inherits from the Microsoft.Build.Utilities.Task class, and overide the Execute() method.
Something like
public class CleanXAML : Task
{
}
Then you spefify (either in your build file, or an external .tasks file that you import, the task name and the path to the DLL you just built)
<UsingTask AssemblyFile="C:\customtasks\XamlTasks.dll"
TaskName="Rob.CustomTasks.Xaml.CleanXaml"/>
That enables you to invoke this like any other MsBuild task
<CleanXaml Source="$(PathtoOriginalXaml)"
Destination="$(SourceCodePath)\$(cleanXaml.xaml)" />
From there you need to figure out the best way to "inject" this into your build process. Depending on how you are building (msbuild, vs2010, teambuild, or teambuild workflow) there are different ways to do this. Essentially you need this to happen BEFORE the CoreCompile target is invoked and make sure your "output xaml" properly replaces what CSC.exe is going to expect.
Do some searches on MsBuild tasks for more info, or ask any question you've got here.
I would highly recommend this approach vs. using a CallEXE task in MSBuild, b/c this way the MSBuild properties and items stay in context so you are just moving from build step to build step, vs sidetracking the whole thing to do the transform, then hoping it keeps working.
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.
I am using Visual Studio 2008 and I get the following error message when trying to open one of my Forms:
Could not find endpoint element with
name 'WSHttpBinding_ICommon' and
contract 'CommonWCF.ICommon' in the
ServiceModel client configuration
section. This might be because no
configuration file was found for your
application, or because no endpoint
element matching this name could be
found in the client element.
And the following stack trace
at
System.ComponentModel.ReflectPropertyDescriptor.SetValue(Object
component, Object value) at
System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializePropertyAssignStatement(IDesignerSerializationManager
manager, CodeAssignStatement
statement,
CodePropertyReferenceExpression
propertyReferenceEx, Boolean
reportError) at
System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeAssignStatement(IDesignerSerializationManager
manager, CodeAssignStatement
statement) at
System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeStatement(IDesignerSerializationManager
manager, CodeStatement statement)
And yet I do have the element suggested in my App.Config and everything works at run-time. However, whenever I try to open the form I get this message, which is not too bad because I can ignore it, but when I do many of the controls (those with anchors on the right side and/or the bottom) are shifted and my grids automatically regain all the columns from their datasource which (the columns) I had previously removed.
Any suggestions/workarounds? Is this a Visual Studio 2008 bug?
There's another approach to debug the devenv process (visual studio) in design time, like stated
here
This helped when opening form in design mode throws exception (i.e. shows error to user).
Here is a summary from that article:
Open a new Visual Studio instance.
Open any source file. This is required so that Visual Studio lets you attach to a process.
Attach the new Visual Studio instance to the first one. The Visual Studio process is called devenv.exe. You only need to attach to managed code.
Set Visual Studio to break on Common Language Runtime exceptions - Thrown and User-handled.
Close the problematic form, and reopen it.
This should result in an exception caught inside your code in the second instance of Visual Studio!
Where are you using the endpoint? Do you really need it there or can you only call on it during runtime? You can use the Component.DesignMode property to determine whether you are in design mode so you can prevent the calls to the endpoint being made. To fully debug your design time experience follow the instructions in this article.
I use
if (LicenseManager.UsageMode == LicenseUsageMode.Designtime)
{
return;
}
To check for Design Mode in both the Constructor if it does anything other than InitializeComponent() and the Load Method if it has one.
I had a similar error once in a form that tried to make a database call during constructor initialization.
Unfortunately, Component.DesignMode doesn't get set until after the constructor finishes!