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.
Related
I have a class library with few interfaces and the implementing classes categorized in different folders. I have generated the class diagrams of the interfaces in the project, but not able to see the relationships to the classes derived from these.
When i try to choose "Show Derived Interfaces" from the context menu of the interface, i get the below error:
Though in the same folder there are classes which are implemented from that interface.
Thanks in advance for any hint in finding the correct way.
Any hint on how to establish manual relationships between the interfaces and classes would also help. I have tried from the Toolbox -> Inheritance option, but not could not do it.
I am using Visual Studio 2022 Community Edition
Correction: I am able to create the relationships manually (from the Toolbox -> Inheritance option) between classes and its base class type.The problem i see when i try to draw the relationship from the class to its base interface.
I can reproduce your issue:
I notice your metioned:
Though in the same folder there are classes which are implemented from
that interface.
But the feature 'Show Derived Interfaces' will not pass focus to the class, but to pass focus to the interface.
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
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.
Visual Studio includes a refactoring function called "Extract Interface" that generates an interface based on a class implementation.
The extracted interfaces are Internal by default. Problem is, we end up changing nearly all of them to Public.
Does anyone know why it's Internal by default? Better yet, is there a way to customize this to default to Public?
It might work if you change the Visual Studio template for interfaces (I haven't tried that but assume this should work).
For Visual Studio 2008 the template is stored at
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates
\CSharp\Code\1033\Interface.zip"
This is described in more detail in this answer.
I don't have a reference, but I have a wild guess as to why it is internal by default.
Let's say you have 3 projects / assemblies: log4net (a 3rd party API), MyApp.Util, and MyApp.Web (a Web project). Web references Util, which references log4net. Web does not reference log4net, and you want to keep it that way.
Inside of DAL, say you have an internal class, and one of its members references a type defined in log4net. It could be the return type or one of the parameter types of a method, or the type of a property.
Let's say you extract an interface from the aforementioned class, including the aforementioned member that references log4net. Well, if you make that member public (part of a public interface) and reference a type that implements it, you then require that the Web project reference log4net.
By making the interface internal, Web may continue to be ignorant of log4net.
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.