Search Results

Search found 6912 results on 277 pages for 'assembly resolution'.

Page 81/277 | < Previous Page | 77 78 79 80 81 82 83 84 85 86 87 88  | Next Page >

  • UserAppDataPath in WPF

    - by psheriff
    In Windows Forms applications you were able to get to your user's roaming profile directory very easily using the Application.UserAppDataPath property. This folder allows you to store information for your program in a custom folder specifically for your program. The format of this directory looks like this: C:\Users\YOUR NAME\AppData\Roaming\COMPANY NAME\APPLICATION NAME\APPLICATION VERSION For example, on my Windows 7 64-bit system, this folder would look like this for a Windows Forms Application: C:\Users\PSheriff\AppData\Roaming\PDSA, Inc.\WindowsFormsApplication1\1.0.0.0 For some reason Microsoft did not expose this property from the Application object of WPF applications. I guess they think that we don't need this property in WPF? Well, sometimes we still do need to get at this folder. You have two choices on how to retrieve this property. Add a reference to the System.Windows.Forms.dll to your WPF application and use this property directly. Or, you can write your own method to build the same path. If you add a reference to the System.Windows.Forms.dll you will need to use System.Windows.Forms.Application.UserAppDataPath to access this property. Create a GetUserAppDataPath Method in WPF If you want to build this path you can do so with just a few method calls in WPF using Reflection. The code below shows this fairly simple method to retrieve the same folder as shown above. C#using System.Reflection; public string GetUserAppDataPath(){  string path = string.Empty;  Assembly assm;  Type at;  object[] r;   // Get the .EXE assembly  assm = Assembly.GetEntryAssembly();  // Get a 'Type' of the AssemblyCompanyAttribute  at = typeof(AssemblyCompanyAttribute);  // Get a collection of custom attributes from the .EXE assembly  r = assm.GetCustomAttributes(at, false);  // Get the Company Attribute  AssemblyCompanyAttribute ct =                 ((AssemblyCompanyAttribute)(r[0]));  // Build the User App Data Path  path = Environment.GetFolderPath(              Environment.SpecialFolder.ApplicationData);  path += @"\" + ct.Company;  path += @"\" + assm.GetName().Version.ToString();   return path;} Visual BasicPublic Function GetUserAppDataPath() As String  Dim path As String = String.Empty  Dim assm As Assembly  Dim at As Type  Dim r As Object()   ' Get the .EXE assembly  assm = Assembly.GetEntryAssembly()  ' Get a 'Type' of the AssemblyCompanyAttribute  at = GetType(AssemblyCompanyAttribute)  ' Get a collection of custom attributes from the .EXE assembly  r = assm.GetCustomAttributes(at, False)  ' Get the Company Attribute  Dim ct As AssemblyCompanyAttribute = _                 DirectCast(r(0), AssemblyCompanyAttribute)  ' Build the User App Data Path  path = Environment.GetFolderPath( _                 Environment.SpecialFolder.ApplicationData)  path &= "\" & ct.Company  path &= "\" & assm.GetName().Version.ToString()   Return pathEnd Function Summary Getting the User Application Data Path folder in WPF is fairly simple with just a few method calls using Reflection. Of course, there is absolutely no reason you cannot just add a reference to the System.Windows.Forms.dll to your WPF application and use that Application object. After all, System.Windows.Forms.dll is a part of the .NET Framework and can be used from WPF with no issues at all. NOTE: Visit http://www.pdsa.com/downloads to get more tips and tricks like this one. Good Luck with your Coding,Paul Sheriff ** SPECIAL OFFER FOR MY BLOG READERS **We frequently offer a FREE gift for readers of my blog. Visit http://www.pdsa.com/Event/Blog for your FREE gift!

    Read the article

  • New Location for .NET 4 GAC

    - by Ricardo Peres
    .NET 4 newcomers may have realised that the old GAC location (%WINDIR%\Assembly) does not contain .NET 4 global assembly cache assemblies. Indeed, they have moved to %WINDIR%\Microsoft.NET\Assembly. It is worth noting that this folder does not use the shell extension that the older one uses, which prevents us from directly looking at the folder's contents, which, IMO, is nice (I mean, the new behavior). The old folder continues to host pre-.NET 4 assemblies.

    Read the article

  • What does * address(found in printf) mean in assembly?

    - by Mask
    Disassembling printf doesn't give much info: (gdb) disas printf Dump of assembler code for function printf: 0x00401b38 <printf+0>: jmp *0x405130 0x00401b3e <printf+6>: nop 0x00401b3f <printf+7>: nop End of assembler dump. (gdb) disas 0x405130 Dump of assembler code for function _imp__printf: 0x00405130 <_imp__printf+0>: je 0x405184 <_imp__vfprintf+76> 0x00405132 <_imp__printf+2>: add %al,(%eax) How is it implemented under the hood? Why disassembling doesn't help? What does * mean before 0x405130?

    Read the article

  • PostSharp, Obfuscation, and IL

    - by Simon Cooper
    Aspect-oriented programming (AOP) is a relatively new programming paradigm. Originating at Xerox PARC in 1994, the paradigm was first made available for general-purpose development as an extension to Java in 2001. From there, it has quickly been adapted for use in all the common languages used today. In the .NET world, one of the primary AOP toolkits is PostSharp. Attributes and AOP Normally, attributes in .NET are entirely a metadata construct. Apart from a few special attributes in the .NET framework, they have no effect whatsoever on how a class or method executes within the CLR. Only by using reflection at runtime can you access any attributes declared on a type or type member. PostSharp changes this. By declaring a custom attribute that derives from PostSharp.Aspects.Aspect, applying it to types and type members, and running the resulting assembly through the PostSharp postprocessor, you can essentially declare 'clever' attributes that change the behaviour of whatever the aspect has been applied to at runtime. A simple example of this is logging. By declaring a TraceAttribute that derives from OnMethodBoundaryAspect, you can automatically log when a method has been executed: public class TraceAttribute : PostSharp.Aspects.OnMethodBoundaryAspect { public override void OnEntry(MethodExecutionArgs args) { MethodBase method = args.Method; System.Diagnostics.Trace.WriteLine( String.Format( "Entering {0}.{1}.", method.DeclaringType.FullName, method.Name)); } public override void OnExit(MethodExecutionArgs args) { MethodBase method = args.Method; System.Diagnostics.Trace.WriteLine( String.Format( "Leaving {0}.{1}.", method.DeclaringType.FullName, method.Name)); } } [Trace] public void MethodToLog() { ... } Now, whenever MethodToLog is executed, the aspect will automatically log entry and exit, without having to add the logging code to MethodToLog itself. PostSharp Performance Now this does introduce a performance overhead - as you can see, the aspect allows access to the MethodBase of the method the aspect has been applied to. If you were limited to C#, you would be forced to retrieve each MethodBase instance using Type.GetMethod(), matching on the method name and signature. This is slow. Fortunately, PostSharp is not limited to C#. It can use any instruction available in IL. And in IL, you can do some very neat things. Ldtoken C# allows you to get the Type object corresponding to a specific type name using the typeof operator: Type t = typeof(Random); The C# compiler compiles this operator to the following IL: ldtoken [mscorlib]System.Random call class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle( valuetype [mscorlib]System.RuntimeTypeHandle) The ldtoken instruction obtains a special handle to a type called a RuntimeTypeHandle, and from that, the Type object can be obtained using GetTypeFromHandle. These are both relatively fast operations - no string lookup is required, only direct assembly and CLR constructs are used. However, a little-known feature is that ldtoken is not just limited to types; it can also get information on methods and fields, encapsulated in a RuntimeMethodHandle or RuntimeFieldHandle: // get a MethodBase for String.EndsWith(string) ldtoken method instance bool [mscorlib]System.String::EndsWith(string) call class [mscorlib]System.Reflection.MethodBase [mscorlib]System.Reflection.MethodBase::GetMethodFromHandle( valuetype [mscorlib]System.RuntimeMethodHandle) // get a FieldInfo for the String.Empty field ldtoken field string [mscorlib]System.String::Empty call class [mscorlib]System.Reflection.FieldInfo [mscorlib]System.Reflection.FieldInfo::GetFieldFromHandle( valuetype [mscorlib]System.RuntimeFieldHandle) These usages of ldtoken aren't usable from C# or VB, and aren't likely to be added anytime soon (Eric Lippert's done a blog post on the possibility of adding infoof, methodof or fieldof operators to C#). However, PostSharp deals directly with IL, and so can use ldtoken to get MethodBase objects quickly and cheaply, without having to resort to string lookups. The kicker However, there are problems. Because ldtoken for methods or fields isn't accessible from C# or VB, it hasn't been as well-tested as ldtoken for types. This has resulted in various obscure bugs in most versions of the CLR when dealing with ldtoken and methods, and specifically, generic methods and methods of generic types. This means that PostSharp was behaving incorrectly, or just plain crashing, when aspects were applied to methods that were generic in some way. So, PostSharp has to work around this. Without using the metadata tokens directly, the only way to get the MethodBase of generic methods is to use reflection: Type.GetMethod(), passing in the method name as a string along with information on the signature. Now, this works fine. It's slower than using ldtoken directly, but it works, and this only has to be done for generic methods. Unfortunately, this poses problems when the assembly is obfuscated. PostSharp and Obfuscation When using ldtoken, obfuscators don't affect how PostSharp operates. Because the ldtoken instruction directly references the type, method or field within the assembly, it is unaffected if the name of the object is changed by an obfuscator. However, the indirect loading used for generic methods was breaking, because that uses the name of the method when the assembly is put through the PostSharp postprocessor to lookup the MethodBase at runtime. If the name then changes, PostSharp can't find it anymore, and the assembly breaks. So, PostSharp needs to know about any changes an obfuscator does to an assembly. The way PostSharp does this is by adding another layer of indirection. When PostSharp obfuscation support is enabled, it includes an extra 'name table' resource in the assembly, consisting of a series of method & type names. When PostSharp needs to lookup a method using reflection, instead of encoding the method name directly, it looks up the method name at a fixed offset inside that name table: MethodBase genericMethod = typeof(ContainingClass).GetMethod(GetNameAtIndex(22)); PostSharp.NameTable resource: ... 20: get_Prop1 21: set_Prop1 22: DoFoo 23: GetWibble When the assembly is later processed by an obfuscator, the obfuscator can replace all the method and type names within the name table with their new name. That way, the reflection lookups performed by PostSharp will now use the new names, and everything will work as expected: MethodBase genericMethod = typeof(#kGy).GetMethod(GetNameAtIndex(22)); PostSharp.NameTable resource: ... 20: #kkA 21: #zAb 22: #EF5a 23: #2tg As you can see, this requires direct support by an obfuscator in order to perform these rewrites. Dotfuscator supports it, and now, starting with SmartAssembly 6.6.4, SmartAssembly does too. So, a relatively simple solution to a tricky problem, with some CLR bugs thrown in for good measure. You don't see those every day!

    Read the article

  • Best C# database communication technique

    - by user65439
    A few days ago I read a reply to a question where people said that the days of writing queries within your c# code are long gone. I'm not sure what the specific person meant with the comment but it got me thinking. At the company I'm currently working at we maintain an assembly containing all the queries to the database (let's call it Queries), this assembly is reference by a QueryService (Retrieve the correct queries) assembly which in turn is referenced by a UnitOfWork assembly (The database connector classes, we have different connector classes for SQL, MySQL etc.). We use these three assemblies to perform operations on our database and all queries/commands are written in our C# code. Is there a better way to communicate with the database and is there a better way to communicate with different database types?

    Read the article

  • Why cant partial methods be public if the implementation is in the same assembly?

    - by Simon
    According to this http://msdn.microsoft.com/en-us/library/wa80x488.aspx "Partial methods are implicitly private" So you can have this // Definition in file1.cs partial void Method1(); // Implementation in file2.cs partial void Method1() { // method body } But you cant have this // Definition in file1.cs public partial void Method1(); // Implementation in file2.cs public partial void Method1() { // method body } But why is this? Is there some reason the compiler cant handle public partial methods?

    Read the article

  • adding custom SSIS transformation to visual studio toolbox fails

    - by ryangaraygay
    Just very recently I encountered an issue in deploying a custom SSIS component assembly which turns out to be a relative "no-brainer" error if only the clues were more straightforward. Basically after deploying the assembly I could not find my component listed in the "SSIS Data Flow Items" tab list.It turns out that the assembly containing the component just had missing or referenced the incorrect assemblies.I have outlined the steps I took that guided me on the right direction on this blog post of mine : adding custom SSIS transformation to visual studio toolbox fails 

    Read the article

  • Oracle makes Virtualized Java Applications Practical. Announces Brand New Products

    - by blake.connell
    New Oracle Virtual Assembly Builder and Oracle WebLogic Suite Virtualization Option make running Java applications in a virtual environments easy and practical. • Oracle Virtual Assembly Builder is a new product designed to help organizations quickly and easily deploy multi-tier enterprise applications in virtualized environments. It enables administrators to quickly configure and provision these applications. • Oracle WebLogic Suite Virtualization Option delivers Oracle WebLogic Server on Oracle JRockit Virtual Edition delivering 'near-native' performance and increased server density. • Oracle WebLogic Server on Oracle JRockit Virtual Edition runs directly on Oracle VM without a guest operating system, a unique capability resulting in better performance and more application server runtime per system. Oracle WebLogic Suite Virtualization Option and Oracle Virtual Assembly Builder can drive operational efficiency and agility. Customers can dynamically scale up/down the underlying software infrastructure and applications with ease through software automation. Register for a live webinar with Oracle product experts Read the press release For more product information: Oracle Virtual Assembly Builder Oracle WebLogic Suite Virtualization Option

    Read the article

  • PostSharp, Obfuscation, and IL

    - by Simon Cooper
    Aspect-oriented programming (AOP) is a relatively new programming paradigm. Originating at Xerox PARC in 1994, the paradigm was first made available for general-purpose development as an extension to Java in 2001. From there, it has quickly been adapted for use in all the common languages used today. In the .NET world, one of the primary AOP toolkits is PostSharp. Attributes and AOP Normally, attributes in .NET are entirely a metadata construct. Apart from a few special attributes in the .NET framework, they have no effect whatsoever on how a class or method executes within the CLR. Only by using reflection at runtime can you access any attributes declared on a type or type member. PostSharp changes this. By declaring a custom attribute that derives from PostSharp.Aspects.Aspect, applying it to types and type members, and running the resulting assembly through the PostSharp postprocessor, you can essentially declare 'clever' attributes that change the behaviour of whatever the aspect has been applied to at runtime. A simple example of this is logging. By declaring a TraceAttribute that derives from OnMethodBoundaryAspect, you can automatically log when a method has been executed: public class TraceAttribute : PostSharp.Aspects.OnMethodBoundaryAspect { public override void OnEntry(MethodExecutionArgs args) { MethodBase method = args.Method; System.Diagnostics.Trace.WriteLine( String.Format( "Entering {0}.{1}.", method.DeclaringType.FullName, method.Name)); } public override void OnExit(MethodExecutionArgs args) { MethodBase method = args.Method; System.Diagnostics.Trace.WriteLine( String.Format( "Leaving {0}.{1}.", method.DeclaringType.FullName, method.Name)); } } [Trace] public void MethodToLog() { ... } Now, whenever MethodToLog is executed, the aspect will automatically log entry and exit, without having to add the logging code to MethodToLog itself. PostSharp Performance Now this does introduce a performance overhead - as you can see, the aspect allows access to the MethodBase of the method the aspect has been applied to. If you were limited to C#, you would be forced to retrieve each MethodBase instance using Type.GetMethod(), matching on the method name and signature. This is slow. Fortunately, PostSharp is not limited to C#. It can use any instruction available in IL. And in IL, you can do some very neat things. Ldtoken C# allows you to get the Type object corresponding to a specific type name using the typeof operator: Type t = typeof(Random); The C# compiler compiles this operator to the following IL: ldtoken [mscorlib]System.Random call class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle( valuetype [mscorlib]System.RuntimeTypeHandle) The ldtoken instruction obtains a special handle to a type called a RuntimeTypeHandle, and from that, the Type object can be obtained using GetTypeFromHandle. These are both relatively fast operations - no string lookup is required, only direct assembly and CLR constructs are used. However, a little-known feature is that ldtoken is not just limited to types; it can also get information on methods and fields, encapsulated in a RuntimeMethodHandle or RuntimeFieldHandle: // get a MethodBase for String.EndsWith(string) ldtoken method instance bool [mscorlib]System.String::EndsWith(string) call class [mscorlib]System.Reflection.MethodBase [mscorlib]System.Reflection.MethodBase::GetMethodFromHandle( valuetype [mscorlib]System.RuntimeMethodHandle) // get a FieldInfo for the String.Empty field ldtoken field string [mscorlib]System.String::Empty call class [mscorlib]System.Reflection.FieldInfo [mscorlib]System.Reflection.FieldInfo::GetFieldFromHandle( valuetype [mscorlib]System.RuntimeFieldHandle) These usages of ldtoken aren't usable from C# or VB, and aren't likely to be added anytime soon (Eric Lippert's done a blog post on the possibility of adding infoof, methodof or fieldof operators to C#). However, PostSharp deals directly with IL, and so can use ldtoken to get MethodBase objects quickly and cheaply, without having to resort to string lookups. The kicker However, there are problems. Because ldtoken for methods or fields isn't accessible from C# or VB, it hasn't been as well-tested as ldtoken for types. This has resulted in various obscure bugs in most versions of the CLR when dealing with ldtoken and methods, and specifically, generic methods and methods of generic types. This means that PostSharp was behaving incorrectly, or just plain crashing, when aspects were applied to methods that were generic in some way. So, PostSharp has to work around this. Without using the metadata tokens directly, the only way to get the MethodBase of generic methods is to use reflection: Type.GetMethod(), passing in the method name as a string along with information on the signature. Now, this works fine. It's slower than using ldtoken directly, but it works, and this only has to be done for generic methods. Unfortunately, this poses problems when the assembly is obfuscated. PostSharp and Obfuscation When using ldtoken, obfuscators don't affect how PostSharp operates. Because the ldtoken instruction directly references the type, method or field within the assembly, it is unaffected if the name of the object is changed by an obfuscator. However, the indirect loading used for generic methods was breaking, because that uses the name of the method when the assembly is put through the PostSharp postprocessor to lookup the MethodBase at runtime. If the name then changes, PostSharp can't find it anymore, and the assembly breaks. So, PostSharp needs to know about any changes an obfuscator does to an assembly. The way PostSharp does this is by adding another layer of indirection. When PostSharp obfuscation support is enabled, it includes an extra 'name table' resource in the assembly, consisting of a series of method & type names. When PostSharp needs to lookup a method using reflection, instead of encoding the method name directly, it looks up the method name at a fixed offset inside that name table: MethodBase genericMethod = typeof(ContainingClass).GetMethod(GetNameAtIndex(22)); PostSharp.NameTable resource: ... 20: get_Prop1 21: set_Prop1 22: DoFoo 23: GetWibble When the assembly is later processed by an obfuscator, the obfuscator can replace all the method and type names within the name table with their new name. That way, the reflection lookups performed by PostSharp will now use the new names, and everything will work as expected: MethodBase genericMethod = typeof(#kGy).GetMethod(GetNameAtIndex(22)); PostSharp.NameTable resource: ... 20: #kkA 21: #zAb 22: #EF5a 23: #2tg As you can see, this requires direct support by an obfuscator in order to perform these rewrites. Dotfuscator supports it, and now, starting with SmartAssembly 6.6.4, SmartAssembly does too. So, a relatively simple solution to a tricky problem, with some CLR bugs thrown in for good measure. You don't see those every day!

    Read the article

  • Can I use pdb files to step through a 3rd party assembly?

    - by Pure.Krome
    Hi folks, my friend has made a really helpful class library which I use all the time. I usually use Reflector to see what his code does. What I really wanted to do was to step through his code while I'm debugging. So he gave me his .pdb file. Foo.dll (release configuration, compile) Foo.pdb Now, I'm not sure how I can get it to auto break into his code when it throws an exception (his code, at various points, thorws exceptions .. like A first chance exception of type 'System.Web.HttpException' occurred in Foo.dll ... Can I do this? Do i need to setup something with the Symbol Server settings in Visual Studio ? Do i need to get the dll compiled into Debug Configuration and be passed the .dll and .pdb files? Or (and i'm really afraid of this one) .. do i need to have both the .dll, .pdb AND his source code ... I also had a look at this previous SO question, but it sorta didn't help (but proof I've tried to search before asking a question). Can someone help me please?

    Read the article

  • PostSharp, Obfuscation, and IL

    - by simonc
    Aspect-oriented programming (AOP) is a relatively new programming paradigm. Originating at Xerox PARC in 1994, the paradigm was first made available for general-purpose development as an extension to Java in 2001. From there, it has quickly been adapted for use in all the common languages used today. In the .NET world, one of the primary AOP toolkits is PostSharp. Attributes and AOP Normally, attributes in .NET are entirely a metadata construct. Apart from a few special attributes in the .NET framework, they have no effect whatsoever on how a class or method executes within the CLR. Only by using reflection at runtime can you access any attributes declared on a type or type member. PostSharp changes this. By declaring a custom attribute that derives from PostSharp.Aspects.Aspect, applying it to types and type members, and running the resulting assembly through the PostSharp postprocessor, you can essentially declare 'clever' attributes that change the behaviour of whatever the aspect has been applied to at runtime. A simple example of this is logging. By declaring a TraceAttribute that derives from OnMethodBoundaryAspect, you can automatically log when a method has been executed: public class TraceAttribute : PostSharp.Aspects.OnMethodBoundaryAspect { public override void OnEntry(MethodExecutionArgs args) { MethodBase method = args.Method; System.Diagnostics.Trace.WriteLine( String.Format( "Entering {0}.{1}.", method.DeclaringType.FullName, method.Name)); } public override void OnExit(MethodExecutionArgs args) { MethodBase method = args.Method; System.Diagnostics.Trace.WriteLine( String.Format( "Leaving {0}.{1}.", method.DeclaringType.FullName, method.Name)); } } [Trace] public void MethodToLog() { ... } Now, whenever MethodToLog is executed, the aspect will automatically log entry and exit, without having to add the logging code to MethodToLog itself. PostSharp Performance Now this does introduce a performance overhead - as you can see, the aspect allows access to the MethodBase of the method the aspect has been applied to. If you were limited to C#, you would be forced to retrieve each MethodBase instance using Type.GetMethod(), matching on the method name and signature. This is slow. Fortunately, PostSharp is not limited to C#. It can use any instruction available in IL. And in IL, you can do some very neat things. Ldtoken C# allows you to get the Type object corresponding to a specific type name using the typeof operator: Type t = typeof(Random); The C# compiler compiles this operator to the following IL: ldtoken [mscorlib]System.Random call class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle( valuetype [mscorlib]System.RuntimeTypeHandle) The ldtoken instruction obtains a special handle to a type called a RuntimeTypeHandle, and from that, the Type object can be obtained using GetTypeFromHandle. These are both relatively fast operations - no string lookup is required, only direct assembly and CLR constructs are used. However, a little-known feature is that ldtoken is not just limited to types; it can also get information on methods and fields, encapsulated in a RuntimeMethodHandle or RuntimeFieldHandle: // get a MethodBase for String.EndsWith(string) ldtoken method instance bool [mscorlib]System.String::EndsWith(string) call class [mscorlib]System.Reflection.MethodBase [mscorlib]System.Reflection.MethodBase::GetMethodFromHandle( valuetype [mscorlib]System.RuntimeMethodHandle) // get a FieldInfo for the String.Empty field ldtoken field string [mscorlib]System.String::Empty call class [mscorlib]System.Reflection.FieldInfo [mscorlib]System.Reflection.FieldInfo::GetFieldFromHandle( valuetype [mscorlib]System.RuntimeFieldHandle) These usages of ldtoken aren't usable from C# or VB, and aren't likely to be added anytime soon (Eric Lippert's done a blog post on the possibility of adding infoof, methodof or fieldof operators to C#). However, PostSharp deals directly with IL, and so can use ldtoken to get MethodBase objects quickly and cheaply, without having to resort to string lookups. The kicker However, there are problems. Because ldtoken for methods or fields isn't accessible from C# or VB, it hasn't been as well-tested as ldtoken for types. This has resulted in various obscure bugs in most versions of the CLR when dealing with ldtoken and methods, and specifically, generic methods and methods of generic types. This means that PostSharp was behaving incorrectly, or just plain crashing, when aspects were applied to methods that were generic in some way. So, PostSharp has to work around this. Without using the metadata tokens directly, the only way to get the MethodBase of generic methods is to use reflection: Type.GetMethod(), passing in the method name as a string along with information on the signature. Now, this works fine. It's slower than using ldtoken directly, but it works, and this only has to be done for generic methods. Unfortunately, this poses problems when the assembly is obfuscated. PostSharp and Obfuscation When using ldtoken, obfuscators don't affect how PostSharp operates. Because the ldtoken instruction directly references the type, method or field within the assembly, it is unaffected if the name of the object is changed by an obfuscator. However, the indirect loading used for generic methods was breaking, because that uses the name of the method when the assembly is put through the PostSharp postprocessor to lookup the MethodBase at runtime. If the name then changes, PostSharp can't find it anymore, and the assembly breaks. So, PostSharp needs to know about any changes an obfuscator does to an assembly. The way PostSharp does this is by adding another layer of indirection. When PostSharp obfuscation support is enabled, it includes an extra 'name table' resource in the assembly, consisting of a series of method & type names. When PostSharp needs to lookup a method using reflection, instead of encoding the method name directly, it looks up the method name at a fixed offset inside that name table: MethodBase genericMethod = typeof(ContainingClass).GetMethod(GetNameAtIndex(22)); PostSharp.NameTable resource: ... 20: get_Prop1 21: set_Prop1 22: DoFoo 23: GetWibble When the assembly is later processed by an obfuscator, the obfuscator can replace all the method and type names within the name table with their new name. That way, the reflection lookups performed by PostSharp will now use the new names, and everything will work as expected: MethodBase genericMethod = typeof(#kGy).GetMethod(GetNameAtIndex(22)); PostSharp.NameTable resource: ... 20: #kkA 21: #zAb 22: #EF5a 23: #2tg As you can see, this requires direct support by an obfuscator in order to perform these rewrites. Dotfuscator supports it, and now, starting with SmartAssembly 6.6.4, SmartAssembly does too. So, a relatively simple solution to a tricky problem, with some CLR bugs thrown in for good measure. You don't see those every day! Cross posted from Simple Talk.

    Read the article

  • Do I need to force the GAC to reload an assembly? Is this possible?

    - by Ben McCormack
    I've added types to my .NET classes that I'm using for COM interop. To get it to work with my VB6 application, I unregistered the DLL and re-registered it (using regasm). I then uninstalled and reinstalled it to the GAC (using gacutil). The types are showing up in the VB6 object explorer, but when I run the application in the VB6 IDE, it breaks on the line that instantiates the new types with the error: Automation Errror - The System cannot find the file specified. I thought this odd since I had already updated the GAC, so I uninstalled the dll from the GAC and got the exact same error, which seems to indicate that the older version of the dll is already in memory and needs to be "reloaded" so that the newer DLL is in memory. Is this possible, and if so, what do I need to do?

    Read the article

  • Using PreApplicationStartMethod for ASP.NET 4.0 Application to Initialize assemblies

    - by ChrisD
    Sometimes your ASP.NET application needs to hook up some code before even the Application is started. Assemblies supports a custom attribute called PreApplicationStartMethod which can be applied to any assembly that should be loaded to your ASP.NET application, and the ASP.NET engine will call the method you specify within it before actually running any of code defined in the application. Lets discuss how to use it using Steps : 1. Add an assembly to an application and add this custom attribute to the AssemblyInfo.cs. Remember, the method you speicify for initialize should be public static void method without any argument. Lets define a method Initialize. You need to write : [assembly:PreApplicationStartMethod(typeof(MyInitializer.InitializeType), "InitializeApp")] 2. After you define this to an assembly you need to add some code inside InitializeType.InitializeApp method within the assembly. public static class InitializeType {     public static void InitializeApp()     {           // Initialize application     } } 3. You must reference this class library so that when the application starts and ASP.NET starts loading the dependent assemblies, it will call the method InitializeApp automatically. Warning Even though you can use this attribute easily, you should be aware that you can define these kind of method in all of your assemblies that you reference, but there is no guarantee in what order each of the method to be called. Hence it is recommended to define this method to be isolated and without side effect of other dependent assemblies. The method InitializeApp will be called way before the Application_start event or even before the App_code is compiled. This attribute is mainly used to write code for registering assemblies or build providers. Read Documentation I hope this post would come helpful.

    Read the article

  • Detecting Screen Resolution to load alternative CSS a good idea?

    - by jdln
    Im working with a graphic designer who constantly wants to make websites larger than the 960 pixels i recommend. I can do a certain amount with liquid layouts but id really love to be able to load different CSS for larger resolutions. I googled it and found the link below, but im worried that I havnt heard more about this. Is this is a reliable method? Im concerned as I would have thought that more people would want to do this. http://www.ilovecolors.com.ar/detect-screen-size-css-style/ Thanks

    Read the article

  • mailto fails in IE with long body. any resolution?

    - by MedicineMan
    I am having a problem using Internet Explorer 8 (IE8) to open mailto links with long messages. After the user clicks on the link, IE changes to an about:blank page and never completes the call to outlook to create an email Here's an example: <a href="mailto:[email protected]?subject=123456789&amp;body=111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111">mailto fails in IE8</a> If I shorten the list of 1's, the email is generated and can be sent. Is this a known IE issue? What are the limitations?

    Read the article

  • Layers - Logical seperation vs physical

    - by P.Brian.Mackey
    Some programmers recommend logical seperation of layers over physical. For example, given a DL, this means we create a DL namespace not a DL assembly. Benefits include: faster compilation time simpler deployment Faster startup time for your program Less assemblies to reference Im on a small team of 5 devs. We have over 50 assemblies to maintain. IMO this ratio is far from ideal. I prefer an extreme programming approach. Where if 100 assemblies are easier to maintain than 10,000...then 1 assembly must be easier than 100. Given technical limits, we should strive for < 5 assemblies. New assemblies are created out of technical need not layer requirements. Developers are worried for a few reasons. A. People like to work in their own environment so they dont step on eachothers toes. B. Microsoft tends to create new assemblies. E.G. Asp.net has its own DLL, so does winforms. Etc. C. Devs view this drive for a common assembly as a threat. Some team members Have a tendency to change the common layer without regard for how it will impact dependencies. My personal view: I view A. as silos, aka cowboy programming and suggest we implement branching to create isolation. C. First, that is a human problem and we shouldnt create technical work arounds for human behavior. Second, my goal is not to put everything in common. Rather, I want partitions to be made in namespaces not assemblies. Having a shared assembly doesnt make everything common. I want the community to chime in and tell me if Ive gone off my rocker. Is a drive for a single assembly or my viewpoint illogical or otherwise a bad idea?

    Read the article

  • Does the java JFC hash table use seperate chaining resolution? Can I traverse each list in the table

    - by Matt
    I have written a program to store a bunch of strings in a JFC hash table. There are defiantly collisions going on, but I don't really know how it is handling them. My ultimate goal is to print the number of occurrences of each string in the table, and traversing the bucket or list would work nicely. Or maybe counting the collisions? Or do you have another idea of how I could get a count of the elements?

    Read the article

  • How can I create a DOTNET COM interop assembly for Classic ASP that does not sequentially block othe

    - by Alex Waddell
    Setup -- Create a simple COM addin through DOTNET/C# that does nothing but sleep on the current thread for 5 seconds. namespace ComTest { [ComVisible(true)] [ProgId("ComTester.Tester")] [Guid("D4D0BF9C-C169-4e5f-B28B-AFA194B29340")] [ClassInterface(ClassInterfaceType.AutoDual)] public class Tester { [STAThread()] public string Test() { System.Threading.Thread.Sleep(5000); return DateTime.Now.ToString(); } } } From an ASP page, call the test component: <%@ Language=VBScript %> <%option explicit%> <%response.Buffer=false%> <% dim test set test = CreateObject("ComTester.Tester") %> <HTML> <HEAD></HEAD> <BODY> <% Response.Write(test.Test()) set test = nothing %> </BODY> </HTML> When run on a windows 2003 server, the test.asp page blocks ALL OTHER threads in the site while the COM components sleeps. How can I create a COM component for ASP that does not block all ASP worker threads?

    Read the article

< Previous Page | 77 78 79 80 81 82 83 84 85 86 87 88  | Next Page >