I have a visual studio solution with a couple of C# projects. One of them contains my domain classes and has no infrastructure dependencies and another contains classes that depend on various 3rd party libraries, it's what you'd call an infrastructure project.
For each class in my domain project I have to write a corresponding class in my infrastructure project which contains just some boilerplate code required for using a feature of one of the 3rd party dependencies so I'd like to generate that automatically whenever my domain class is changed.
I was able to generate the classes containing this boilerplate code by creating a source generator with a ISyntaxReceiver that adds the abstract syntax tree of my domain classes for which I need to generate the boilerplate code to a list which is then used by my source generator to create the required classes. I then added this source generator as a project reference to my domain project but I have a problem: the infrastructure classes I need to generate inherit from a class of a 3rd party dependency so I have to add that 3rd party dependency to my domain project.
What I tried to do was to add my source generator as a project reference to my infrastructure project (which already references the 3rd party dependency, and also my domain project) but the source generator does not run because the ISyntaxReceiver's OnVisitSyntaxNode method does not get called for any of the classes in the referenced domain project.
Does anyone know if it's possible to create a source generator that generates code based on classes in projects referenced by the project that references that source generator?
I am aware of the AnalyzerAdditionalFiles, but seems like that should be used for making generation decisions based on more than just C# code
Related
I have a project that requires certain functions, and I have created an interface for these functions. If the implementations of the interface is to be performed by external parties, what should be the correct way to do this?
The idea I have is to create a class library project (MyInterface), define my interface (IModule) in this project, compile this and give the DLL (MyInterface.dll) to the external parties. The external parties would develop/implement using the DLL as a reference, then give me their final DLL. My main project would reference the MyInterface project, as well as all the implementations. In my code, I would do something like this:
IModule module = new ImplementationA();
module.DoSomething();
module = new ImplementationB(); // Change implementation at runtime
Is this approach correct? Are there better alternatives?
Side question: Is this strategy design pattern? Or facade?
I would probably use configuration to load the 3rd party assembly at runtime, look for a single factory type, create a singleton instance, and create each implementation class through the factory. This way you can give all of your assemblies to a 3rd party, and they can build and update their component at any time. They depend on your code, but you don't depend on theirs.
I don't know much about your project or situation, but I would consider publishing a nuget package of your interface and allow the third parties to install it. That gives you the power of versioning when you need to make changes to your interface(s). You publish the change(s) as a new version and then they can update their installed package of your dll accordingly. That at least gives them a concrete way to develop against what you require in a controlled, robust manner.
In case you aren't familiar with nuget packages, in Visual Studio you can right click the necessary project with the dll within the solution and select Pack. You can also change pack settings by going to the Package tab in the project properties (same context menu on the project, select Properties).
You can also do dotnet pack through the command line, which has a lot of command line arguments that you can leverage.
Whichever way you go about it, you can publish your nuget package to nuget.org, to some other service with an artifact feed, or simply to a file on disk.
Helpful Nuget Package References:
Installing a nuget package
Create and publish a nuget package
As for your question about the pattern, typically when you switch implementations like that at run time that is the strategy pattern at work. The facade is when you use a single class to abstract away multiple instances of different sub-system classes. So for example lets say you have operation classes for GetUser, UpdateUser and DeleteUser. Your facade could be a single class called UserManager and within that class you would expose functions of each user operation. Inside those functions you would be accessing each individual instance of each operation class and passing the call on to those functions internally. In this example, inside the facade you know you are working with 3 classes. From the perspective of code/callers outside of it, they only know about the single UserManager class.
We are looking to implement reusable functionality within more than one of our products.
What I would like to do is:
Create a C# project that contains one or more Azure Functions (static methods with the FunctionNameAttribute attached to them)
Turn this project into a NuGet package
Reference this NuGet package in an Azure Functions project
Have the function(s) from the NuGet package exposed in the project it is being used in
Whilst I find that it all compiles, the functions in the NuGet package are not "found" on startup and are ignored. I can see that this could be desirable for security reasons, but I'm wondering if there is a way to overwrite how the functions runtime operates to say "scan this assembly and use any functions contained within it".
Even having that custom code would be preferable to the situation in which we find ourselves - having joint functionality in our package that is referenced by two different products, but each of the products having to create a duplicate set of functions that then call the common code.
I think that the best approach for this would be through git submodules and not Nuget packages.
Create a project that both products will reference. A base class that will have some methods that you can overwrite or just reuse in both solutions by inhering it from the base class.
Following your comment, let's try this workflow:
1 - Write a AZF project with Swagger, for all the Product common operations.
2 - Write a new Project to have the ProductBase class that will consume all the Product REST endpoints.
3 - Convert the Consume project to a Nuget Packages.
4 - Install it in both Projects A and B, and Inherit the Base product class
I have a very basic java module that contains two interfaces (IOrder, IOrderItem) and two classes that implement those interfaces (Order, OrderItem).
After creating a xamarin binding library in VS2017 I only see the two interfaces.
Checking out the api.xml shows me that both classes are recognized and I even see their generated classes in the obj\Debug\generated\src folder of my project.
Why aren't these classes making it into my object explorer? What am I missing that links these generated files into the project itself?
I have been given dlls for entities, service classes. I need to add additional properties to Entity in my web project. How can I do that? I cannot create new classes extending dll classes because service dll returns Entity class defined in the dlls.
Is there any way?
thanks
Sanjivani
If I have a class library with a certain number of public classes (5 for this example) and I have 3 projects that depend on this library (for this example) and I decide to change one of the classes, but only 1 of the 3 projects depend on that class.
Do I need to compile/link/deploy all 3 projects?
Basically does .NET depend on the names of the classes or does it have some type of addressing dependency? (I have a c++ background, so I know in c++ I would have to redeploy all 3 projects).
If the class inherits from an interface, and you do not change the interface (but only the class implementation), then you don't have to change the dependent assemblies if they rely solely on the interface for communication with the class.
If you change a class's API (like a method signature or name) on which a dependent assembly relies, then you have to fix the dependent assembly to use the new API. This includes changes to the name of the class itself.
So the key here is to provide a stable API. If you change the API, then you have to change the code that depends on the API. If an assembly is not dependent (i.e. it doesn't rely on any API dependencies that you are changing), then you don't have to re-deploy it.
If you recompile the class library project, creating a new DLL, you do not have to recompile the projects that do not depend on the changes to the DLL as long as:
the public interface that each project depends on does not change in a breaking manner.
The projects are still compatible with the new version number of the DLL.
If your dependent projects do not require a specific version number or version range of the DLL, the version consideration does not apply.