I am using the AlphaMobileControls library for the .NET Compact Framework. I am using AlphaImage.CreateFromResource(imageResourceName) to create an AlphaImage object. The problem is that this method is throwing a NullReferenceException. Looking at the code for this method, the problem is that this line of code is returning null:
MemoryStream stream =
(MemoryStream)Assembly.GetCallingAssembly().GetManifestResourceStream(imageResourceName);
This was working fine before, and now it is not and I can't figure out why. It seems that I am passing a valid resource name. It is a resource that I added using the Resources tab of the project properties. Also in the Resources folder the image file is there and the Build Action is set to Embedded Resource. I even used this code to retrieve the available resources, and the one I am using was one of the returned values:
string[] names = Assembly.GetCallingAssembly().GetManifestResourceNames();
Then I was thinking that maybe by the time the AlphaImage.CreateFromResource() method code is running the available resources might be different. So I modified the code to include the above statement and then throw an InvalidOperationException if the passed resource is not an available resource. When I run the program and step through the code with the debugger, the added code is not there anymore and an InvalidOperationException is not thrown and the code will run until the NullReferenceException occurs. I searched my projects to see if maybe there was a reference to another version of AlphaMobileControls other than the one with the modified code, but I could not find any.
Any help will be appreciated, thanks in advance!
Inspect the result from Assembly.GetCallingAssembly().GetManifestResourceNames(); and see whether the resource name you are looking for appears here. When it doesn't, your settings on the properties of the resource (specifically "Build action: Embedded resource") will probably be set incorrect. Otherwise, maybe a folder has been renamed and you need to change the value of imageResourceName.
Aren basically answered this for me with his comment. You need to call AlphaImage.CreateFromResource() from the assembly that has the required resource. Thanks Aren.
The change I made that caused this to stop working was that I moved the class that was calling AlphaImage.CreateFromResource() into a separate library from the one that had the image resource. Therefore Assembly.GetCallingAssembly() is returning the assembly that does not have the resource.
Related
My goal is to display information about the methods of some classes in an uploaded dll. Loading the assembly, finding the desired classes and their methods was already successfully done. Now I was trying to show whether a method is declared "async" or not.
I found a thread that tells me how to do it: How can I tell if a C# method is async/await via reflection?
Anyway, while testing, when I call this
(AsyncStateMachineAttribute)methodInfo.GetCustomAttribute(typeof(AsyncStateMachineAttribute))
I got a System.IO.FileNotFoundException - "Could not load file or assembly '{assembly identifier}' or one of its dependencies. The system cannot find the file specified.".
I found this exception in an unanswered thread, but it did not help me: How to prevent MemberInfo.IsDefined from throwing FileNotFoundException on irrelevant attributes?
I understand that the method I am looking at has an attribute that my code does not know. I do not want to load that reference because it is only a test case and many other different attributes can be found in the same situation.
So, I need an answer to one of two questions:
Is there a way to get the attribute "AsyncStateMachineAttribute", if it exists, ignoring the errors on other attributes?
Is there another way to check whether a method (from MethodInfo) is async?
Thanks in advance! :)
I have the following code. The CustomControlHelper generates an instance of an object via reflection. At this stage we don't know what type of object we are dealing with. We do know it will be a CustomControl, but we don't know if it implements any particular interface or if it extends any other classes. The following code is trying to establish whether the loaded control implements the IRichAdminCustomControl interface.
Object obj = CustomControlHelper.GetControl(cc.Id, cc.ControlClass);
if(obj != null)
{
bool isWhatWeWant = (obj is IRichAdminCustomControl);
return isWhatWeWant;
}
That's all fine, but I've noticed that when I know I have an object that implements IRichAdminCustomControl, the expression evaluates to false.
Okay, this is where it gets really weird. If I inspect the code when debugging, the expression evaluates to true, but then if I immediately let the code run and inspect the result, it evaluates to false (I've attached an animated gif below to illustrate).
Has anyone come across weirdness like this before and if so, what on earth is causing it?
Incidentally, I believe the product I'm using uses Spring.NET to provide dependency injection in the CustomControlHelper.
If you are using Visual Studio 2010 SP1, I came across this bug:
Misreporting of variable values when debugging x64 code
There is a workaround on that page, posted by Microsoft:
You can either set all projects to compile to x86, or create an intermediate initialised variable declaration to ensure the debugger reports the correct value of the variable being examined.
Try this as a workaround:
bool isWhatWeWant = true;
isWhatWeWant &= (obj is IRichAdminCustomControl);
bool finalValue = isWhatWeWant; // this line should fix isWhatWeWant too in the debugger
return finalValue;
EDIT: seems like VS2012 also encounters similar problems in specific conditions.
Two possibilities come to mind. The first is that your interface name is generic enough that it could already be in the namespace somewhere. Try fully qualifying the interface in the is clause. The second possibility is that you might be running the code as part of a constructor, or being called indirectly by a constructor. Any reflection like stuff needs to be done after we are certain the application has fully loaded.
So I found the answer. It was because I had two copies of the dll in different locations. I had one copy in the bin of my back-end application and one in a shared external directory that gets dynamically loaded by the backend app.
I should explain; this application consists of two apps running in tandem, a frontend app and a backend app. Ordinarily, you place "Custom Controls" into your frontend app. These controls are then copied on application start to a external directory that is accessible to the backend app.
In this case, I had logic in my Custom Control library that needed to be accessed in the backend app - so I had to make a reference to it... which ended up with the backend app having two references to the same class. D'oh! And OF COURSE that's going to work when you're debugging.
Solution was to split my extra logic into its own project and reference THAT in the backend app.
I'm not going to "accept" my own answer here because, although it solved my specific problem, the solution is a bit TOO specific to the apps I'm working with and would be unlikely to help anyone else.
This happened to me once and even though I never came to a conclusion as to why it was happening I believed the PDB files that were being loaded with the debugging symbols where out of sync. So, by "cleaning" the solution and then rebuilding the solution this weird issue went away.
I know similar questions have been asked a million times. I've read them and I still cannot get to the bottom of this. I'm using the Novell.Directory.Ldap c# library in my code (Winforms, c#). It works very similar to the microsoft ldap libraries but it can also access the attributes specific to Novell eDirectory.
using Novell.Direcotry.Ldap; is in there. I also added the reference and pointed it to the Novell.Directory.Ldap.dll file.
string LDAPServerIP = "12.34.56.78";
string serverUserName = "cn=Rrunner,o=acme";
string serverPassword = "#nvi1";
LdapConnection ldapConn = new LdapConnection();
MessageBox.Show(ldapConn.ToString());
ldapConn.SecureSocketLayer = true;
ldapConn.Connect(LDAPServerIP, 636);
ldapConn.Bind(serverUserName, serverPassword);
I get a NullReferenceException when it gets to the ldapConn.Connect() method.
Stepping through in the debugger is can see the ldapConn object, and it is a Novell.Directory.Ldap.LdapConnection object and seems to have sensible values assigned to it. For example, it does get SSL set to true, and at the point of the exception it even has already had the Host(string) variable set to the LDAPServerIP, and the Port(int) set to 636 just as the ldapConn.Connect() ordered. Given this information, I put a try/catch on just that statement to get past it since it is putting the attribute in anyways. It then will also get the exception on the Bind() method, and bind did put the appropriate values (userDN and password) into the object as well.
That section of code I copied directly from another program I use/write and it works perfectly fine in that so I don't know why it shouldn't work in this program. The only difference is that this is a differnt project in Visual Studio.
Given that, I've tried going through the things again that could be different because its a different project:
I've tried verifying that the reference to the Novell supplied is in the project. I'm fairly certain that part must be working because the object in memory is of the correct type and has a bunch of attributes that my program doesn't tell it about so they had to come from that dll file.
The SSL cert exists on my computer in a spot where .net can find it as this is the same computer that I develop the program that does connect to LDAP successfully.
What am I misssing? It seems like it has to be something really simple.
I found it finally. It was something really simple, and something that had to be set due to being a different project. I needed to add Mono.Security.dll and the reference to it.
Ive been looking everywhere for a possible solution to this but can't seem to find an answer. My issue is that I have a few classes that need to completely hidden from Assembly.getTypes, as I'm writing a plugin for an application, and it's picking up types that I need to remain hidden (this happens even if they are declared as private or internal classes).
anyone know how to either alter what assembly.GetTyes returns, or an ,aficionado attribute that will keep those types from being listed?
This is quite a hack and is very fragile, but could work.
Create 2 assemblies -- one for the plug-in and the second for the other types. The second would be placed in another known directory and loaded dynamically into the first when needed. (For example, via Assembly.LoadFrom.)
The first assembly would then be placed in the plug-in directory and only ever publish its types. This very fragile because you would likely have to hard-code a path to the second assembly and you run the risk of the file getting deleted or moved.
EDIT
#SLaks' comment takes away the fragility of this solution. If you embed the second assembly as a resource and load it at run-time, the app calling Assembly.GetTypes won't see the types you want hidden.
This is not possible.
Sorry.
Code that calls Assembly.GetTypes() should typically filter for only public types.
Welcome to managed code. Complete type information is necessary to .NET's type verifier. Only native code can be hidden from .NET metadata, and then you give up the portability and permissions supported by pure MSIL.
Related to an earlier question I asked, I've seen that there's both LoadComponent() and XamlReader.Load(). They're similar enough that I'm not quite sure which one I should use in what case.
So, in essence, what's the difference between the two?
Thanks!
MSDN:
LoadComponent
XamlReader.Load()
Speculation
I would guess that LoadComponent calls XamlReader.Load(). LoadComponent looks more like an application level service and is probably used by the application itself to load all of the xaml resources. XamlReader is the specific library call for what you want.
Think about it as LoadComponent is an Application Service where XamlReader is the library containing the functionality.
Application.LoadComponent:Application will first preload resources as a 'Package' and register it in PreloadedPackage class, when calling LoadComponent method, wpf first check if package exsits and resource exists, then check if resouse is xaml or baml, finally load the resource stream with provided BaseUri
If resource is baml, LoadComponent will use Baml2006Reader, otherwise use XamlReader to process resource stream.
XamlReader.Load can load xaml resources outside the assembly.