This question already has answers here:
What Are Some Good .NET Profilers?
(30 answers)
Closed 4 years ago.
There is a system composed of an ASP.NET web application, .NET windows services and shared .NET libraries. It has large number of classes, each containing multiple methods.
How to conveniently collect runtime data about execution of methods without having to modify each single class and method? The goal is to register execution of all the methods that are part of the system (except .NET Framework classes). The purpose of collecting this data is to learn what features of the system are never used by the users. We already performed static code analysis as well as eliminated pages that were never displayed based on IIS logs.
You could use post-compilation tools to instrument your code with the necessary logging mechanisms in order to collect necessary data. There are existing tools that you could use such as PostSharp or Fody.Tracer.
Alternatively, if those tools are for some reason not the exact what you need, you could write your own post-compilation weaver. This can be done by using Mono.Cecil library. With this library you would be able to take your compiled assemblies, instrument them with the logging code only in places you think is necessary and then collect and analyse the logs.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I need to create some functionality in our large C# software package that will use .NET DLLs from a third party software package. Not all of our customers are going to use this package. If I add a reference to those DLLs in Visual Studio I can access the objects I need from them, but I assume that will break the build for other developers in my company who won't have this third party package installed.
What is the correct approach for me to be able to access this third party functionality without breaking things for customers and developers who won't use that package? Do I need to address this by creating my own DLL as a layer of indirection? Do I need to dynamically load the third party DLLs at runtime?
To my understanding, a .NET DLL is not loaded by the application until it is actually needed. This means if the DLL is referenced, but no code branch making use of it is reached, it is not required to be present. Perhaps it is not necessary to implement something in this case.
That being said, it is possible to use a technique termed 'hot loading', which means using reflection to explicitly access types contained in a .NET DLL. The technique is discussed in this question.
First, check if it has already been loaded; if not, check if the .DLL exists, and if so, dynamically load it with System.Reflection.Assembly.LoadFile. The reason you want to check if it has already been loaded is because the dynamic loader will often waste memory by loading additional instances.
It will be a bit more work, but by handling this dynamically, you can enable/disable functionality in your application that requires the assembly based on whether it is present, which will minimize unnecessary error reports from people trying to use it when it is not there.
Be careful in referencing the assembly when it is not there; although .NET will usually dynamically load only when an assembly is needed, newer versions are getting more aggressive in how they load, to prevent startup delays, so even if it works now (and that depends on the overall configuration), it may not work in the near future.
It looks like I will be using dynamic loading as described enter link description here. Props to Alberto for showing how to use the dynamic keyword with his answer.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'd like to know how to inject a C# DLL into a Unity process. Since Unity hosts a CLR (as it runs mono MSIL), I'd imagine I could play around with reflection.
So how would I inject a .NET DLL into a .Net process, and what can I do in terms of reflection once I'm in there?
For example. Say i have a game that uses unity3d as the engine, with most of the code writtin in C# (that doesn't matter since unity seems to compile unityscript to .net anyway). I want to extend this already written codebase with my own code.
Typically in a normal native process you would start reversing the code, finding pointers and data structures as they appear in memory, gaining an understanding of the code as you go along. Then writing the same structures in your code, obtain rwx access to that processes memory (typically by injecting a dll into that process) and then going to town.
Since unity uses .net however, i was wondering if there was a better way. I'd like to leverage the reflection capabilities of the .net framework. For this I think I'd need to get my code injected into the unity process. From there i don't know how a workflow might be.
Long story short: I'd like to inject a DLL, with a payload written in C# (hopefully using reflection instead of pointers), into a foreign process (i don't have control over it at compile time), and mess around with the processes internal classes and functions.
One option is the .cctor function (module initializer), which does NOT run on assembly load, but rather the first invocation into your dll.
Previously, I thought this was the earliest you could get with .net, but apparently I'm mistaken:
There's a horrible, nasty hack that lets you run a DllMain in .net - C# equivalent of DllMain in C (WinAPI)
This is certainly not something that was intended by the creators of .net. Be careful when using it.
This gets your code running, and once in, you can invoke System.Reflection like normal and do whatever you want.
Drop the DLL into an asset folder
Assets/Libs/MyLib.dll
Open any CS file and in the MonoDevelop solution add the reference.
When you quit MonoDevelop Unity will refetch the solution file and import the dll's reference.
You can now use your library from Unity code that you write in MonoDevelop just as normal.
There will be no difference between your code and any other API like System.IO.
Pay attention to the .NET framework versions, don't mix code.
To be safe, use .NET 2.0. ...wait... I don't remember but it should be 2.0... don't quote me on that.
Once you're there you can do everything as normal.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm looking for a way to programmatically determine which version of the .NET Framework an application pool is using in IIS, at runtime, and for a website application to then use that information to choose which *.config file it should use.
Is it possible? I'm not sure where to begin.
I don't know of a good way to do this per application pool. This would be tough to manage, and would easily break when app pools are upgrades are performed, and people wouldn't know why. This isn't generally the way most do this, so I would avoid it if possible. Instead, I suggest the following alternatives:
For development and testing purposes, we use the NConfig library (Install-Package NConfig) to allow for different configurations per hostname.
However, we don't use it in production since we would have to maintain configurations for every server in the web farm, which often are started via automated processes anyway so we don't even know hostnames most of the time. So for managing settings per environment in those cases, we use msdeploy transform configurations. (There are lots of tutorials around the net on how to use those.) It also supports multiple configuration settings via profiles, if you need them.
Also, in your comments you mention something about having to run a installer to install a site that works in .Net 2.0 and 4.0. I'm guessing that means you want your configuration to be different depending which the site is installed on? I would discourage that. It would be easier to get it to install and run in .Net 2.0 (not 4.0) if there are important differences that you can't get to work in both (which would be the better option).
In the end though, there is no 'easy' install for a web site. You have to get the .Net versions (user may not even have 2.0 if they have an old enough Windows :( ), security settings, IIS versions, IIS plugins, often some kind of SQL, connection strings, and so on. If an MSI install of this app is imperative though, then know it's not going to be easy, and you'll most likely need to customize a lot of the process.
You might have enough in looking at the value of property System.Environment.Version
which basically:
Gets a Version object that describes the major, minor, build, and
revision numbers of the common language runtime.
Based on that you can load your config and/or load new application domain with the new configs.
This question already has answers here:
Strategy for cross-language (java and c#) object serialization
(9 answers)
Closed 9 years ago.
I am a .Net developer who looks a bit at android (using Android Studio). For my Android App I wrote some additional Tools (.NET/Windows) that allow me to save Data in XML-files which contain complex serialized objects created by standard Framework-Methods.
Can I read serialized objects created by the .NET-Framework directly into Android applications? If not: Is there any workaround to "convert" these files?
There are many ways to do this. A schema may help, depending on approach. One quick/simple way to make POJO from XML on android is to use the simple framework. It takes some extra time to create the class with right extra decoration, then framework will push/pull XML to POJO. Other ways are to use other 3rd party tools to take the XML (or schema) to generate the java classes and what not, but the overhead of deserialization and/or Android availability of the JARs etc may be a headache. That's why/how I ended up using the simple framework.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We have a desktop application which needs to expose API.
Some people say: API should have an abstraction layer so actual implementation can change in future versions.
Others say: API should be version specific. So an API which uses version X will only work with it. Version X+1 will also deploy the dll's of version X in order not to break existing usage. This is claimed to be aligned with how frameworks like .Net or Silverlight works.
What is your opinion?
Some questions that you should consider:
What's the likely expectations of your users?
Are you likely to need to make breaking changes between versions?
How much would it cost you in development effort to maintain compatibility across versions, based on any roadmap you currently have?
My opinion is that you should maintain API compatibility across versions if at all possible. Microsoft have achieved it, mostly, with Office and it's why there are so many add-ins, accessories and LOB applications built around them. I, for example, wrote an application on-top of Access XP that used Excel automation quite heavily and it works without error in Office 2010. That's what I call compatibility!
I have found that versioning an interface is a useful tool to implement breaking changes.
You should do your best to get your API interfaces right the first time.
When you have a breaking change (changing existing signatures, so client code must be recompiled), you must change the interface, and when you do so you can change the version. Non-breaking changes (e.g. adding new features to a different class) shouldn't change the version, if you can avoid it.
Use the idea of closed for modification, open for extension. Any parts of the API you expose should not change in future versions if at all possible. (Parts you don't expose can be modified, provided they still function the same). A programmer expects to use an API and have that code work for it's lifetime, without worrying about the version he is referencing.
Consider that in later versions of the API, you might expose new features that each user of your API might want to adopt - but he already has code written against the old version of the API. He should be able to plug in the new parts without rewriting his old code (Assuming the new parts don't rely on the breaking changes).
If there are breaking changes to be made, you should not remove the old way of doing it, but mark it [Obsolete], and give a clear message on how it should be updated to the newer API.
If you are using Net as a reference you should notice that they take a hybrid approach, they use a bit of both, do not confuse CLR version with NET version.
You should consider your app uses in order to find the answer for you.
My money is on mantaining API compatibility accross all versions as possible.
However there are drawback to that as well.
Regards
If you do decide to go version specific make sure you're very up front with your users. I've missed deadlines half a dozen times do to my vendors changing their web services without notifying me and having to scramble to come up with a solution