We currently have multiple .NET projects that we have developed using Visual Studio. Each project has a reference to a shared dll that contains some helper classes.
Let's say I have an instance class named 'Helper1' with a public method named 'Save()'. Does anyone know of a way for me to search a group of projects to determine which projects/line the Save() method belonging to the Helper1 class is being invoked?
Basically, I want a list of where the Helper1 class' Save() method is being used among multiple projects.
This is not as simple as doing a text search. There could be many other classes in these projects that also have a Save() method which is being invoked, but I don't care about them. I only want to know about the Save() method belonging to the Helper1 class.
This means, the tool performing the search needs to be smart enough to understand the current namespace it is searching in. When a Save() method is found, the search tool needs to determine if the Save() method belongs to the Helper1 class or to some other class.
Note: There is no dynamic dependency injection happening in these projects, so we know at compile time which classes are being used.
Load all the dlls into "reflector" (the free version is fine)
navigate to the method you are interested in
bring up the analyser (ctrl+r I believe)
job done
Red Gate's .NET Reflector can do this, even in the free version.
The "Analyze" feature will tell you where specific types are used, exposed, and instantiated:
If you find yourself needing something a little bit more high powered, you might look into Tom Carter's Dependency Structure Matrix Plugin. This works with Reflector to give you a more powerful way of tracking inter-module dependencies. You can read an article about it here.
Related
How to filter Intellisense, Auto Completion, in Visual Studio C#, to show only members that the Project defined, or that are contained in the assembly from which I am currently editing code. Or that are defined in the actual class/interface that I am completing code one, and not the parent class?
Very often when I want to invoke/call/use a member that I defined. I am currently in a habbit of navigating to the class which I want to invoke a function on, copy/remember the name, then complete the code.
The thing is that I would find it very useful (in reducing redundant hand movement), while coding, to be able to view only the functionality that is written by me. Because in the environment that I am writing each object has at least 200 built in members that appear in most intellisense suggestions. And these built in suggestions are not part of my Assembly or Project. they are from the Engine. Similarly C# itself defines all these ToString() like members for each System.Object of which everything is derived from. To find the User-Defined members amongst all these System and Engine defined members is a hassle.
I searched google and forum for answers, to no avail. Also I don't have the money for solutions, so I would appreciate if it would be a free solution.
I afraid the answer is negative.
For now, IntelliSense cannot suppress the display of built-in properties, methods, and so on from the root cause to only show the custom parameter methods, and so on.
However, since VS2017, IntelliSense has only added filters, which can only be filtered by fields, methods, classes, keywords and so on.But you cannot filter by customization or built-in.
Suggestion
I suggest you put the class name, method naming specification(add some fields to prompt the method's role such as function select_AllManagers). After that, you can type a few more keywords to narrow IntelliSense down.
In addition, if you still want to get this point, you could report it to DC forum to raise the Support Team's attention. Hope this could help you.
I created a VS 2010 class library. Marked the assembly for Com Visibility. Signed the assembly with a strong key. Created my class, have my entry point method available.
The library works fine from a test project in C#.
I regasm the class library to gac, via:
c:\windows\microsoft.net\framework\v4.0.30319\regasm testdll.dll /tlb: testdll.tlb /codebase
Include the tlb file as a reference in my VB6 project. I find it through resources 'browse' so its there.
When i try to instantiate the class... its empty. the public method that should be available via the public class doesn't show.
Dim objTest as testdll.testclass
set objTest = new testdll.testclass
objTest.testmethod <--- this 'testmethod' doesn't display in intellisense... nothing does.
In addition i tried calling the 'testdll.testclass' via CreateObject, i get the error "ActiveX component can't create object"
Now i have other projects i've done COM visibility for and i've tried comparing the difference, but i don't see any. I can't understand why it isn't working.
Any clues??? tx very much.
Just use an interface... one you define or to use the [ClassInterface(ClassInterfaceType.AutoDual)]
there are comments online you can find that indicate not to use autodual, but if you control the complete usage of your library, it seems like an 'ok' way to go.
I tried all sorts of ways to simulate / understand why my one project didn't need an interface to be visible by an vb project, without success. i had originally thought perhaps possible that it was because that project implemented an IDisposable Interface (the ONLY interface used in the C# projects that is com visible) but that didn't turn out to be the reason. Anyway I don't want to waste anyone else's time on this. thanks for the responses.
this link provides ample information on the subject:
http://anturcynhyrfus.blogspot.com/2011/03/creating-com-visible-c-component.html
I am fairly new to development, and Visual Studio 2010.
I have a solution with a Test Project:
In my solution, there are two projects: "TPS" and "TPS.Tests"
In the TPS project, in the namespace "TPS.Models" I have defined a bunch of classes, and two interfaces.
I have created a Test Class in the TPS.Tests project, and have added "using TPS.Models;"
I attempt to implement the interface by typing it out (e.g. public class FakeObjectClass : IObjectClass), but it isn't recognised (so I can't get the auto-implement going, which would be handy as I have over 100 methods)
Typing in the class, in Intellisense, I can see all the objects defined in my model, but none of the interfaces.
Google has been unusually silent on the search combinations I have tried. I am hoping there is some simple explanation/fix?
Thanks in advance for your time.
Tim.
If you haven't specified an access modifier when defining the Interface, it will default to internal and not be visible to other assemblies.
Make sure that you defined your interface as
public interface IMyInterface
A few things to check:
- Does your "TPS.Tests" project have a reference to the "TPS" project?
- Are your interfaces in the "TPS.Models" namespace? Putting the files in a sub-directory of the project, such as "Interfaces", can affect their namespace.
- Are the interfaces marked as Public?
Also, I would suggest using an Isolation (aka "Mocking" framework) to create your fake objects, such as Moq, Rhino.Mocks, etc, rather than rolling your own fake objects for most situations.
I want to add usage statistics for a .NET 4.0 library I write on CodePlex.
I try to follow the step described here but my problem lies with the fact that what I write is a library and not an application.
One of the steps is put the Setup and Teardown attributes. I thought about adding the Setup attribute on a static constructor or a different place that will run once per usage of the library. My problem lies with the Teardown attribute that should be placed on code that ends the usage. I don't know where to put this attribute.
Is it possible to get usage statistics on a library?
Maybe I can register on an event that will fire when the application unloads the dll?
This looks like a typical honeypot giveaway, designed to commit you to the retail edition of their obfuscator. It's a tough business, few play this game better than Preemptive. Yes, using attributes is not going work for a library. The only possible candidate would be a finalizer. And you do not want your code to contact some website while the finalizer thread is running.
Take a look at the retail edition of their product. I bet it has a way to invoke the methods that are normally injected by their obfuscator directly. The class constructor is an obvious candidate for "Setup". An event handler for the AppDomain.ProcessExit event could be a possible location for the "Teardown" call. This also might avoid having to run the obfuscator at all, not undesirable in an open source project.
My question isn't so much about use of interfaces but more of a project organization nature.
Note: I am using VisualStudio in a multi-layered application.
Should my Interface files live in a separate project from their implementations? My initial thought is that it would be useful to separate out all my service interfaces into their own project (and a project for my initial implementations) so that down the road the implementation/concrete project may be removed and replaced with a new one if necessary.
To clarify with an example: Suppose I have a business layer Interface called IBusinessService which lives in the MyApp.Business.Services namespace. My implementation FooBusinessService would exist in the same namespace, but a different project in VisualStudio. If later on the implementation needed to be reworked, a developer could remove the reference to the FooService.proj and replace it with a reference to BarService.proj.
This seems like it would declutter the app solution by allowing you to reference a project with only interfaces without also acquiring concrete implementations (which may be obsolete or of no use to you), but am I missing something?
I'm with you. I prefer to put my interfaces in a separate project AND in a different namespace. The classic example is with data access classes. You want to be able to code an MSSQL version and a MySQL version, both implementing the same interface. As such, I prefer that the interface definition be in a separate assembly/project. Here's an example of how I lay out assemblies and namespaces:
Elder.DataAccess.Core - contains the interfaces and common utilities
Elder.DataAccess.MSSQL - specific MSSQL implementations of the interfaces
Elder.DataAccess.MySQL - specific MySQL implementations of the interfaces
This allows me to modify the implementations without touching the project that contains the interface definitions. This helps me with version control and change tracking, too. There might be other ways to skin this cat, so I'll be eager to see other folks' answers.