I have implemented a CustomTraceListener for use with Enterprise Library 5. From the TraceData method, I need to crawl the stack up 6 levels to my class that had the actual logging call, I need a property from there. I don't think I want a StackFrame climb because that only gets the class and not the object, right? What is the best way to get at the (string) property I need?
This is on Framework 4.0, thanks.
I don't think you can get (parameters) values from the .NET stack from the program itself, only methods, properties, classes, ie: anything that comes from .NET metadata.
If you want values, here are a some solutions:
instrument your code before compilation, adding lines of code to capture parameters values
instrument your code after compilation, with things like PostSharp for example (disclaimer: I'm not affiliated in any way)
write a .NET profiler, but this must be an external program. There a existing tools that do this already, like this one: CLR profiler. Version 4 of the CLR profiler (available here) comes with the source.
Related
I found many languages provides some way to change code runtime. Many people ask queries regarding how to change code in this or that language runtime. Here I mean by change code is that rewrite code itself at runtime by using reflection or something else.
I have around 6 year of experience in Java application development. I never come again any problem where I have to change code at time.
Can anyone explain why we require to change code at runtime?
I have experienced three huge benefits of changing code at runtime:
Fixing bugs in a production environment without shutting down the application server. This allowed us to fix bugs on just some part of the application without interrupting the whole system.
Possibility of changing the business rule without having to deploy a new version of the application. A quicker deploy of features.
Writing unit test is easier. For example, you can mock dependencies, add some desired behaviour to some objects and etc. Spock Framework does well this.
Of course, we had this benefits because we have a very well defined development process on how to proceed on this situations.
At times you may need to call a method based on the input, that was received earlier in the program.
It could be used for dynamic calculation of value based on the key index, where every key is calculated in a different way or calculation requires fetching required data from different sources. Instead of using switch statement you can invoke a method dynamically using methodName+indexOfTheKey.
I have a portable class library that targets WSA, NET45 and WP8, and I would also like to target SL5. What's silly is that 99% of the library code is SL- compliant, but in has a couple of places where I make a call to a reflection API to retrieve type property or field:
var fields = myType.GetTypeInfo().DeclaredFields;
Unfortunately GetTypeInfo is not available in SL5, so the above code won't compile. So I basically have there options:
Don't target SL5 from the PCL, so I will need to keep a separate library for Silverlight.
Extract from PCL code that uses reflection, so PCL will need to resolve this dependency on start.
Do something smart at runtime, so PCL can detect what methods are available and call the appropriate one.
Option 1 is ok, but I'd rather find an alternative to maintaining a duplicate library.
Option 2 would be ok if I had to extract a large piece of functionality so it would be worth introducing a bootstraper. When it's a couple of lines that don't compile it's silly to drag DI/IoC.
So I am thinking about option 3 without clear understanding if it's even possible. Reflection is my friend, but it's a reflection API mismatch that I am trying to overcome.
Advises/experience sharing is appreciated.
After playing with the code it struck me that I could simple use old way of retrieving fields:
var fields = myType.GetFields(BindingFlags.Public | BindingFlags.Static);
I was under impression that because of reflection API change this syntax is not available in PCL, but it was in fact opposite: using this syntax I can target both .NET 4.0.3, .NET 4.5, .NET for WSA, WP8 and SL5.
How about this?
Reflection.Assembly = Reflection.IntrospectionExtensions.GetTypeInfo(GetType(*anyTypeInAssembly*)).Assembly
We're currently migrating our ASP Intranet to .NET and we started to develop this Intranet in one ASP.NET website. This, however, raised some problems regarding Visual Studio (performance, compile-time, ...).
Because our Intranet basically exists of modules, we want to seperate our project in subprojects in Visual Studio (each module is a subproject).
This raises also some problems because the modules have references to each other.
Module X uses Module Y and vice versa... (circular dependencies).
What's the best way to develop such an Intranet?
I'll will give an example because it's difficult to explain.
We have a module to maintain our employees. Each employee has different documents (a contract, documents created by the employee, ...).
All documents inside our Intranet our maintained by a document module.
The employee-module needs to reference the document-module.
What if in the future I need to reference the employee-module in the document-module?
What's the best way to solve this?
It sounds to me like you have two problems.
First you need to break the business orientated functionality of the system down into cohesive parts; in terms of Object Orientated design there's a few principles which you should be using to guide your thinking:
Common Reuse Principle
Common Closure Principle
The idea is that things which are closely related, to the extent that 'if one needs to be changed, they all are likely to need to be changed'.
Single Responsibility Principle
Don't try to have a component do to much.
I think you also need to look at you dependency structure more closely - as soon as you start getting circular references it's probably a sign that you haven't broken the various "things" apart correctly. Maybe you need to understand the problem domain more? It's a common problem - well, not so much a problem as simply a part of designing complex systems.
Once you get this sorted out it will make the second part much easier: system architecture and design.
Luckily there's already a lot of existing material on plugins, try searching by tag, e.g:
https://stackoverflow.com/questions/tagged/plugins+.net
https://stackoverflow.com/questions/tagged/plugins+architecture
Edit:
Assets is defined in a different module than employees. But the Assets-class defines a property 'AssignedTo' which is of the type 'Employee'. I've been breaking my head how to disconnect these two
There two parts to this, and you might want to look at using both:
Using a Common Layer containing simple data structures that all parts of the system can share.
Using Interfaces.
Common Layer / POCO's
POCO stands for "Plain Old CLR Objects", the idea is that POCO's are a simple data structures that you can use for exchanging information between layers - or in your case between modules that need to remain loosely Coupled. POCO's don't contain any business logic. Treat them like you'd treat the String or DateTime types.
So rather than referencing each other, the Asset and Employee classes reference the POCO's.
The idea is to define these in a common assembly that the rest of your application / modules can reference. The assembly which defines these needs to be devoid of unwanted dependencies - which should be easy enough.
Interfaces
This is pretty much the same, but instead of referring to a concrete object (like a POCO) you refer to an interface. These interfaces would be defined in a similar fashion to the POCO's described above (common assembly, no dependencies).
You'd then use a Factory to go and load up the concrete object at runtime. This is basically Dependency Inversion.
So rather than referencing each other, the Asset and Employee classes reference the interfaces, and concrete implementations are instantiated at runtime.
This article might be of assistance for both of the options above: An Introduction to Dependency Inversion
Edit:
I've got the following method GetAsset( int assetID ); In this method, the property asset.AssignedTo (type IAssignable) is filled in. How can I assign this properly?
This depends on where the logic sits, and how you want to architect things.
If you have a Business Logic (BL) Layer - which is mainly a comprehensive Domain Model (DM) (of which both Asset and Employee were members), then it's likely Assets and Members would know about each other, and when you did a call to populate the Asset you'd probably get the appropriate Employee data as well. In this case the BL / DM is asking for the data - not isolated Asset and Member classes.
In this case your "modules" would be another layer that was built on top of the BL / DM described above.
I variation on this is that inside GetAsset() you only get asset data, and atsome point after that you get the employee data separately. No matter how loosely you couple things there is going to have to be some point at which you define the connection between Asset and Employee, even if it's just in data.
This suggests some sort of Register Pattern, a place where "connections" are defined, and anytime you deal with a type which is 'IAssignable' you know you need to check the register for any possible assignments.
I would look into creating interfaces for your plug-ins that way you will be able to add new modules, and as long as they follow the interface specifications your projects will be able to call them without explicitly knowing anything about them.
We use this to create plug-ins for our application. Each plugin in encapsulated in user control that implements a specific interface, then we add new modules whenever we want, and because they are user controls we can store the path to the control in the database, and use load control to load them, and we use the interface to manipulate them, the page that loads them doesn't need to know anything about what they do.
I'm implementing some objects which will have about an equal amount of richness on both the client-side and server side.
In this particular case, I'll be building a (hopefully) little class library to deal with search tokens. So as a pseudo-code example, I'll want to be able to do the equivalent of the following in both Javascript and on the server (C# in my case).
s = new SearchTokenList();
s.Add(new SearchToken(field, value, negation));
What design strategies will help avoid creating a big ball of mud for a library which must span C# and Javascript?
Update: Looking for more of strategies than mechanics. But I'll take any guidance I can get from those who have previously done similar things.
Take a look at Script# by Nikhil Kothari, might help you out. It is a C# to JavaScript compiler.
I think you should check out my C# to JavaScript compiler out at http://jsc.sourceforge.net/
Unlike Script# my jsc compiler works on MSIL level.
WPF Example: AvalonExampleGallery
Contact me if you have any specific questions.
If performance is not critical, you could load the data in JSON or XML and pass it back to server-side and do the processing. I think WCF can generate JavaScript interface out of the box. See .NET by Example: Calling a WCF service from Javascript.
You should be able to run some Javascript code on your .NET server using Microsoft's JScript.NET -- compile it with /target:library and make sure it's CLS-compliant and that you declare that fact with
[assembly:System.CLSCompliant(true)]
or other variants of CLS compliance declarations. Once you've gotten this to work, you could run (a bit of) JS code on both the server (calling it from C#) and the client (calling it from other JS) and more easily ensure equal functionality on both sides.
I am VERY new to ASP.NET. I come from a VB6 / ASP (classic) / SQL Server 2000 background. I am reading a lot about Visual Studio 2008 (have installed it and am poking around). I have read about "reflection" and would like someone to explain, as best as you can to an older developer of the technologies I've written above, what exactly Reflection is and why I would use it... I am having trouble getting my head around that. Thanks!
Reflection is how you can explore the internals of different Types, without normally having access (ie. private, protected, etc members).
It's also used to dynamically load DLL's and get access to types and methods defined in them without statically compiling them into your project.
In a nutshell: Reflection is your toolkit for peeking under the hood of a piece of code.
As to why you would use it, it's generally only used in complex situations, or code analysis. The other common use is for loading precompiled plugins into your project.
Reflection lets you programmatically load an assembly, get a list of all the types in an assembly, get a list of all the properties and methods in these types, etc.
As an example:
myobject.GetType().GetProperty("MyProperty").SetValue(myobject, "wicked!", null)
It allows the internals of an object to be reflected to the outside world (code that is using said objects).
A practical use in statically typed languages like C# (and Java) is to allow invocation of methods/members at runtime via a string (eg the name of the method - perhaps you don't know the name of the method you will use at compile time).
In the context of dynamic languages I haven't heard the term as much (as generally you don't worry about the above), other then perhaps to iterate through a list of methods/members etc...
Reflection is .Net's means to manipulate or extract information of an assembly, class or method at run time. For example, you can create a class at runtime, including it's methods. As stated by monoxide, reflection is used to dynamically load assembly as plugins, or in advance cases, it is used to create .Net compiler targeting .Net, like IronPython.
Updated: You may refer to the topic on metaprogramming and its related topics for more details.
When you build any assembly in .NET (ASP.NET, Windows Forms, Command line, class library etc), a number of meta-data "definition tables" are also created within the assembly storing information about methods, fields and types corresponding to the types, fields and methods you wrote in your code.
The classes in System.Reflection namespace in .NET allow you to enumerate and interate over these tables, providing an "object model" for you to query and access items in these tables.
One common use of Reflection is providing extensibility (plug-ins) to your application. For example, Reflection allows you to load an assembly dynamically from a file path, query its types for a specific useful type (such as an Interface your application can call) and then actually invoke a method on this external assembly.
Custom Attributes also go hand in hand with reflection. For example the NUnit unit testing framework allows you to indicate a testing class and test methods by adding [Test] {TestFixture] attributes to your own code.
However then the NUnit test runner must use Reflection to load your assembly, search for all occurrences of methods that have the test attribute and then actually call your test.
This is simplifying it a lot, however it gives you a good practical example of where Reflection is essential.
Reflection certainly is powerful, however be ware that it allows you to completely disregard the fundamental concept of access modifiers (encapsulation) in object oriented programming.
For example you can easily use it to retrieve a list of Private methods in a class and actually call them. For this reason you need to think carefully about how and where you use it to avoid bypassing encapsulation and very tightly coupling (bad) code.
Reflection is the process of inspecting the metadata of an application. In other words,When reading attributes, you’ve already looked at some of the functionality that reflection
offers. Reflection enables an application to collect information about itself and act on this in-
formation. Reflection is slower than normally executing static code. It can, however, give you
a flexibility that static code can’t provide