I wan to implement IntelliSense support for custom language. Actually it is a customize version of C++. i.e the methods resides in separate files
So my main class is like followings and it has import file MyClassMethods which has all the methods.
public class MyClass {
#import MyClassMethods
// my code goes here
}
So my MyClassMethods fiel looks like following and it has two methods,
public void testMethod1() {
}
public void testMethod2() {
}
Then at the end I want to have IntelliSense features when I working on MyClass. Example when I put dot character on that class in a required place I want to have testMethod1() and testMethod2() in the IntelliSense menu.
Is this possible to achieve and if so how can I achieve this?
Related
I've updated Specflow from the 3.0.225 to the 3.1.62 and I received the error Tests_Integration_MSTestAssemblyHooks: Cannot define more than one method with the AssemblyInitialize attribute inside an assembly.
The reason is obviously that I'd had the [AssemblyInitialize] attribute in my project already. How can I fix it?
The reason is that Specflow generates another file in the background which has the AssemblyInitialize/AssemblyCleanup hooks defined. In order to fix that one should use the hooks provided by Specflow, namely BeforeTestRun/AfterTestRun. Like this:
[Binding] // add the Binding attribute on the class with the assembly level hooks
public abstract class SeleniumTest
{
// it used to be [AssemblyInitialize]
[BeforeTestRun]
public static void AssemblyInitialize(/* note there is no TestContext parameter anymore */)
{
// ...
}
// it used to be [AssemblyCleanup]
[AfterTestRun]
public static void AssemblyCleanup()
{
// ...
}
}
I'm creating a library of MVC6 TagHelpers for a large project.
I find myself writing certain functionality in these TagHelpers again and again.
I'd like to make a base TagHelper that all the others inherit from to remove all the duplicated code.
The issue is this - suppose I create a base TagHelper as below:
public class BaseTagHelper : TagHelper
{
public override void Process(TagHelperContext context, TagHelperOutput output)
{
//Some implementation...
}
}
Now, when I go to write a view, I will have intellisense suggesting the taghelper <base>.
Is there any way I can tell intellisense that this isn't a TagHelper I actually want to use, just a base class containing implementation common to other TagHelpers I've created?
Create it as an abstract class, see some examples in the official MVC Core repo like CacheTagHelperBase
public abstract class BaseTagHelper : TagHelper
{
public override void Process(TagHelperContext context, TagHelperOutput output)
{
//Some base implementation...
}
}
Entity Framework 4, Ninject 3, MVC3
Currently in my web app i have been using a rather rudimentary approach to per request instantiation of an Object Context. So I am experimenting with Ninject, and some old sample code, but I am unsure how to proceed with the following..
Effectively I want to be able in the controller to do the equivalent of: DB_Entities.Current.Albums ... Should i be instantiating a StandardKernel every time?
The sample i was looking at was using the following: MvcApplication.Container.Get(); but in Ninject 3 with the App_Start hookup I dont have access to Container..
My attempt to replicate the above line, is failing at runtime.
using MusicStoreEntities;
using Ninject;
using TestMVC3WithIOC.App_Start;
using System.Data.Objects;
namespace TestMVC3WithIOC.Models
{
public partial class MusicStoreEntities
{
public static MusicStoreEntities Current
{
get
{
using (IKernel kernel = new StandardKernel())
{
return (MusicStoreEntities)kernel.Get<ObjectContext>();
}
}
}
}
}
Also, note, that in App_Start\NinjectWebCommon.cs I have the following modification:
private static void RegisterServices(IKernel kernel)
{
kernel.Bind<ILogger>().To<NLogger>();
kernel.Bind<ObjectContext>().To<MusicStoreEntities>().InRequestScope();
}
Although a workable solution, it seems ill-advised to pass the entire Kernel into a class, because it tends to obscure the classes actual, specific dependencies. A better approach is to pass a factory dependency into your controller's constructor.
public partial class MusicStoreEntities
{
private readonly IEntitiesFactory _factory;
public MusicStoreEntities(IEntitiesFactory factory)
{
_factory = factory;
}
}
IEntitiesFactory has a simple implementation with a single method GetObjectContext().
(I believe also the "Unit of Work" pattern is popular at the moment, but I can't really speak to that as I haven't used it. Maybe worth looking into.)
Ok so let's say I have the following class in C#:
class Foo
{
public void Bar() { Console.WriteLine("FooBar"); }
}
In Visual Studio, whenever I instantiate my class and implement my method intellisense looks like this:
All this is showing is the name, return type and input parameters of my method. When viewing any method inside any of the .Net base classes using intellisense, a description is provided.
How do I add a description for my own methods to intellisense, so anybody who uses a *.dll I have written in the future can understand what my methods do without having to refer to external documentation?
Thanks
Add xml documentation :
/// <summary>
/// Foos something
/// </summary>
public void Foo()
{
}
I create an add-on for the product Foo. There are different versions of Foo, namely version 1, 2, 3 and 4.
These versions have a mostly compatible API, but not fully.
I currently have 5 projects:
DotNetCommon - here are the common methods which could be used if I create an add-on or something other than the Foo product.
FooOne
FooTwo
FooThree
FooFour
The Foo*-projects contains the add-in for version 1-4 of Foo.
There are a lot of duplicated files in the Foo*-projects, as there are a lot of things in the API which are identical for all versions of Foo. It would be nice to separate out everything which is common for all Foo-versions.
Why not just create a common assembly for all versions of Foo called FooCommon?
If I would put all classes which are common for all versions of Foo into a new library project, I would still have to choose which version of Foo the new FooCommon should reference. As said, they are not identical.
Create an interface containing the common methods:
public interface IFoo
{
void CommonMethod1();
void CommonMethod2();
}
Create an abstract base class from IFoo:
public abstract class FooBase : IFoo
{
// Implement the common calls here
public void CommonMethod1()
{
// concrete shared code goes here
}
public void CommonMethod2()
{
// concrete shared code goes here
}
}
Create your one-off code from the FooBase:
public class FooOne : FooBase
{
// concrete code specific to FooOne goes here
}
public class FooTwo : FooBase
{
// concrete code specific to FooTwo goes here
}