I'm working on an designer-heavy application (using Visual C++ 2.0, but a C# solution should still be relevant). My setup is this:
I have a UserControl named "Host"
I'm attempting a UserControl named "Child"
Child contains a property to a class whose type is defined in a different dll entirely, named "mytools.dll"
Child works just fine in the designer. However, when I go to drag "child" onto "host" from the designer, I get the following error:
Failed to create component 'Child'. The error message follows: 'System.io.filenotfoundexception: could not load file or assembly MyTools, Version XXXXXX, Culture=neutral
.....
{unhelpful callstack}
If I comment out the property in "child" that points to the class in mytools.dll, everything designs just peachy. I have the property marked with "Browsable(false), and DesignerSerializable(hidden), and it does not help.
Is there a way for me to explicitly say "Don't load this dll, you won't need it in design time", or some way for me to force a dll to load from the designer programmatically?
Thanks!
If the property is marked 'public' then the UserControl will force the designer to load the external assembly.
You must rework your control to return Object instead of the bad type, and do typecasting if you must keep it public, otherwise, protected should be fine.
No, there's a chicken-and-egg problem here. In order to find the attributes you applied, the designer has to use Reflection to load the Type. Loading the type requires any types used by its members to be loaded as well. Which will cause the CLR to go hunting for your mytools.dll assembly.
The probing path in effect at design time is the one for Visual Studio, not your app's. What exactly that path looks like is murky to me. The toolbox plays a role as well. It makes a copy of the assembly that contains the control in a private directory. The place to look is c:\users\yourname\appdata\local\microsoft\visualstudio\9.0\projectassemblies. This often goes wrong and stray copies are left behind in that directory. I have to clean it out by hand from time to time when I notice that toolbox initialization starts to get slow.
Well, something you can check to see if a copy of mytools.dll is present there as well and isn't an old version. Putting it the GAC is one way to stay out of trouble.
UserControl has a DesignMode property, but I'm not sure if .NET wants to resolve the type beforehand (ie. return null if DesignMode == true).
Alternatively if you're the only developer you could handle the AppDomain.CurrentDomain.AssemblyResolve event and load a dummy assembly yourself.
Related
I need a list of the methods and properties exposed by a COM object. I am able to late bind the object and use some basic methods that I found in an example code snippet but I need to find out the full list of methods and properties on the object.
More info:
I am trying to pull data from a fairly old system and am unable to early bind any of the dlls.
I do have some snippets of example code from the company that creates these dlls (it was packaged with the software), however it does not have code for all of the advanced functionality I am seeing from their example application (which I do not have source code to).
I have already tried using reflection without much success.
Assuming that you don't need to programatically access the information, the easiest way is to the OLE-COM object viewer. The tool is part of the Windows SDK.
Once running, look in the Type Library node and locate the type library of the component that you are using. The Type Library viewer will show you all of the dispatch interfaces defined by the component.
If you can't add the DLL to VB6 in the References dialogue, then there is no Type Library resource embedded in the DLL. If you can load the DLL, you should be able to use F2 to bring up Object Browser, and see all of the properties and methods of the component.
It seems unlikely that you hadn't tried this. So there are three possibilities:
There is an external type library for the component.
You got an error when adding the DLL as a reference, which essentially said the VB IDE couldn't find a type library in the component.
You got an error when adding the DLL as a reference, saying something like "Could not load DLL".
Just in case of 1. - check if there is a TLB or OLB file for this component.
If you got the error in 2. - then you are out of luck. You will require access to documentation and/source code.
If you got the error in 3. - then there is probably a dependent library which has not been registered. Try to find the dependent TLB or DLL, and register it.
I'm using VS2010, and developing a C# WinForms app.
I would like to create a new form, that inherits from a form in a different dll. I right click on my project, hit 'add new item' and then under 'forms' click 'inherited from'.
At this point I get the error: 'Unable to load assembly 'X'. Ensure that the file is a valid .net framewrok assembly'. I hit OK, and then get another error for 'Y' project. They are both C# .net 4.0 winforms projects.
The important note here. I don't care about those two projects. I have 270 projects in my solution, and Neither of them are even control libraries. They are .exes.
So, the question:
Is there someway to mark the entire dll as "Im not going to be using any public types, and i don't want to ever load from the inheritance picker"? If not, is there anything I can look for that would help figure out why these 2 of 270 projects wont load?
I know I can just create a new form and manually type the actual class I want to derive from. I need visual studio to work the intended way, and wanting to avoid shortcuts. Also, i've gone through and marked every single class in both projects as either private or internal.
Thanks!
So, I have a user control UcEx which inherits from Uc. Uc has other custom controls and forms, such as MyTree (a TreeView). MyTree and Uc have localized strings located in an assembly MyResources in the file Common.resx. UcEx is part of another form MainForm.
In this situation everything looks fine, but when I add a new MyTree to the UcEx, which already has 4 inherited objects of type MyTree from Uc, MainForm [design] throws an error:
{Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "MyResources.Common.resources" was correctly embedded or linked into assembly "MyResources" at compile time, or that all the satellite assemblies required are loadable and fully signed.}
I don't understand this since all the other MyTree-s that are already there don't cause any error.
It's not a problem of namespace or assembly name or missing a resource file, so I have no idea where to go from here...
Also when I run a debug, no exception is thrown.
EDIT1: I have already tried changing Build Action to Embedded Resource and Custom Tool as ResXFileCodeGenerator
Change the BuildAction of your ResourseFile(Common.resx) to EmbededResource and try.
I have an application which loads dlls with user controls dynamically. Inside one of the dlls I have a control which shows a button, which, when hit, pops up a new window. Everything would be great but the window does not appear... all I get is the "Cannot locate resource XXX.xaml" message with the name of the xaml which defines the window to pop up.
The window to pop up is created in a command which is binded to the button:
private void onCmdSetIndexValidator(object _param) {
IIndex param = (IIndex)_param;
new IndexValidatorsEditor(param).Show();
}
Any ideas?
Resources in the Window need to be scoped for the assembly where they live. If you access an asset in your Window (Image, Page, etc), you need to specify the assembly it comes from (even if it comes from its own assembly). If you do not specify the assembly, WPF will assume the resource comes from the executing assembly (your client app).
Define the assembly via pack URI's. Example: /nameOfAssembly;component/folder/background.png
It also may help to look at the inner exception value of the original exception. Sometimes this provides clues as to what resource its having trouble locating.
http://msdn.microsoft.com/en-us/library/aa970069.aspx
The solution was simple... the code which loaded my dll was wrong - it used Assembly.LoadFile instead of Assembly.LoadFrom
When I try using a Name="id" and\or x:name="id" I get a compiler error:
The Type 'MyName' was not found. Verify that you are not missing an assembly reference and that all referenced assemblies have been built.
When I don't have this specified my control runs just fine. Any suggestions?
Well, first of all the right syntax is x:Name, although Name by itself usually (but not always) works too.
Does the x:Class on your root-level element match the name (and namespace!) of your code-behind file? I know that some versions of Blend and VS didn't insert the default namespace correctly, and of course if you've changed it from the default you'll need to make sure you've changed the other file as well.
I've run into this before and believe it's a compiler bug. I ended up just sticking a named ContentControl in my XAML and sticking the user control in it from the code behind. Hopefully someone can share an actual fix for this.