I am creating a series of related plugins. Each plugin is for a different entity. Does each plugin have to have it's own assembly? I'm using Visual Studio and I created a second project within the same solution but I can't see the new step in registration tool.
Thanks
It can do, but doesn't have to. That is pretty much your design decision. Consider if you had several classes all implementing IPlugin
public class MyFirstPlugin : IPlugin
{
//implemented as per usual
}
public class MySecondPlugin : IPlugin
{
//implemented as per usual
}
If you were to register that DLL in the plugin registration tool, you would see the following structure:
- Server
- DLL
- MyFirdtPlugin
- MySecondPlugin
You can then add steps to each plugin as desired.
The alternative would be to have one plugin per DLL, which would give you
- Server
- DLL1
- MyFirstPlugin
- DLL2
- MySecondPlugin
I must admit it seems like overkill - but it can also depend on how you are using your solutions.
In addition to glosrob's answer, I'm guessing that you're using the plugin registration tool to register your plugin. If so, you'll need to make sure that after you add your new plugin to the same dll, that you update the plugin dll itself with the registration tool, so you can register the new plugin method that you've created.
Yes, you can create each plugin in a different class library project but this is not a good practice. I'd prefer to collect all plugins into one class library.
Note that after selecting your assembly from the File Dialog you have to click on Load Assembly button to load all classes which implement the IPlugin interface.
To answer the question - no, each new plugin doesn't have to be contained in a new assembly.
To elaborate - it's technically possible to put in all the plugin code in just one project and a single file.
To warn - the above would be a nightmare to manage with all the ifs and buts, so it's a good example of can-but-shouldn't.
To suggest - I usually have a separate project for each entity's plugin and handle all the messages using a switch. On occasion, I might have two or three assemblies but you'll know when it's time to do so as you get there. Usually, one DLL is just enough.
Related
I'm new in docusign.
Currently I'm working on Form development etc..
Can someone tell me where in docusign in Workflow diagram can I create or use own c# class or DLL.
Currently in a calculation stage we are creating many c# functions for field calculation but it must be there an option to use object oriented programming?
Thank you for any help, clue!!!
You can either use a Nuget package directly, that is found either using Nuget Package Manager or directly - https://www.nuget.org/packages/DocuSign.eSign.dll/
Or, you can clone this repo and build it yourself and add it as a project in your solution.
If you want to see some code that is using it and try it out - go to https://github.com/docusign/code-examples-csharp.
I'm having an issue activating the IMvxMessenger using IoC. (Mac, Xamarin Studio, iOS7, Mono 3.2)
I have downloaded NPlus1DaysOfMvvmCross and loaded the N37 Maps project.
Compiled the project and it works fine.
I then added the Cirrious.MvvmCross.Plugins.Messenger.dll to the project and the following code to the app.cs Initialize just below the service IoC call.
CreatableTypes (typeof(IMvxMessenger).Assembly).AsInterfaces ().RegisterAsSingleton ();
I receive and error when compiling that says:
Failed to resolve parameter for parameter id of type Guid when creating Cirrious.MvvmCross.Plugins.Messenger.MvxSubscriptionToken
IMvxMessenger is a plugin and does not need to be registered for IoC in the way you are doing it. Plugins get registered by creating a bootstrap class for each of the plugins you want to use in your project like so:
public class MessengerPluginBootstrap
: MvxPluginBootstrapAction<Cirrious.MvvmCross.Plugins.Messenger.PluginLoader>
{
}
Some plugins with platform dependent parts, such as the Visibility Plugin, need to be registered in a different manner on iOS, because it is silly:
public class VisibilityPluginBootstrap
: MvxLoaderPluginBootstrapAction<Cirrious.MvvmCross.Plugins.Visibility.PluginLoader, Cirrious.MvvmCross.Plugins.Visibility.Touch.Plugin>
{
}
This way you should be able to use the types inside of the Plugin using IoC.
This doesn't sound like it's anything to do with ios7
The line of code
CreatableTypes(typeof(IMvxMessenger).Assembly)
.AsInterfaces()
.RegisterAsSingleton ();
will:
take all the creatable types in the assembly (ie any non-abstract types with a public constructor)
will then find their interfaces
will then create a new instance and register that as the singleton implementation for the interfaces.
For the Messenger plugin, that includes trying to new and register an MvxSubscriptionToken as an IDisposable singleton - although this fails as the public constructor for MvxSubscriptionToken requires a Guid (and you haven't told MvvmCross how to supply that - so the construction fails)
If you did want to just register specific types in an Assembly, then normally you'd add a EndingWith("PostFix") clause - like the default Mvx nuget templates do with Services as the postfix.
If you did want to just register a single specific class from an Assembly, then you'd often just do that as:
Mvx.RegisterSingleton<IThing>(new Thing());
However, for plugins - which are just a convention-based set of rules placed on top of IoC - what you normally want to do is to call EnsureLoaded() on the plugin manager for the PluginLoader for that plugin.
The easiest way to do that is to include a Bootstrap file in the UI project - see the examples in N=8 - https://github.com/slodge/NPlus1DaysOfMvvmCross/tree/master/N-09-Location%20And%20Message/Location.Touch/Bootstrap - your application's Setup will use Reflection to find that Type and will then call EnsureLoaded on the plugin for you.
For more on IoC in MvvmCross, see https://github.com/slodge/MvvmCross/wiki/Service-Location-and-Inversion-of-Control
For more on plugins, see https://github.com/slodge/MvvmCross/wiki/MvvmCross-plugins
Make sure the plugin is installed in the Core project AND the Android project.
My question is quite related to this post but i am unable to assemble all the pieces together. I am trying to fetch SystemUser using ServiceContext object, XrmServiceContext via Linq in Plugin code as shown below:
var serviceFactory = serviceProvider.GetOrganizationServiceFactory();
var service = serviceFactory.CreateOrganizationService(context.UserId);
using (var xrmServiceContext = new XrmServiceContext(service))
{
var user = xrmServiceContext.SystemUserSet
.Where(x => x.SystemUserId.Value == context.UserId)
.First();
}
But i am getting the following InvalidCastException:
Unable to cast object of type 'Microsoft.Xrm.Sdk.Entity' to type 'Xrm.SystemUser'.
Whereas the Early-bound classes generated through CrmSvcUtil placed in separate assembly (other than plugin assembly).
This is quite strange as if i place the generated Early-bound classes inside the plugin assembly it works just fine.
My little research led me to create separate OrganizationServiceProxy object but why should i create one when i am already creating IOrganizationService using serviceFactory.CreateOrganizationService(context.UserId)
So how to solve this issue by keeping generated code outside plugin assembly?
Add another suggestion:
you can also put the early-bond assembly in C:\Program Files\Microsoft Dynamics CRM\CRMWeb\bin, if you chose opion register plugin in database when registering plugin.
The behavior is not strange at all.
If you put the Early-Bound classes in another assembly is quite normal that your plugin can't find it, specially if the assembly is not inside the server GAC (for example).
This because when you register a plugin, you register only the plugin dll, not all the referenced assemblies.
If you want to keep the generate code outside the plugin assembly you have two options:
Register (and keep updated) the early bound assembly inside the GAC (if you are on-premise, online you can't do it)
Use ILMerge to combine the two assemblies before you registered the plugin assembly
ILMerge link:
http://www.microsoft.com/en-us/download/details.aspx?id=17630
I am trying to implement validation and in reading:
https://github.com/ServiceStack/ServiceStack/wiki/Validation
I see this method being used. It doesn't seem to be on the Funq container, what am I missing?
//This method scans the assembly for validators
container.RegisterValidators(typeof(UserValidator).Assembly);
If you think a method is missing in ServiceStack it's most likely an extension method. RegisterValidators() is an extension method in the ServiceStack.ServiceInterface.Validation namespace.
You should consider using ReSharper as there as it eliminates a whole class of issues with C# development including locating methods, auto including namespaces, auto referencing of dlls, etc.
Otherwise if for some reason you want to continue without ReSharper you can use the T short-cut looking in the ServiceStack GitHub Repo which helps find files, otherwise use Ctrl+Shift+F to do a solution-wide text search in a local fork of ServiceStack.
Basics:
Visual Studio 2010
WP7 SDK 7.1 RC
AutoMapper added to project via NuGet
Ask for more!
Problem:
I'm getting the following error at runtime:
Could not load type 'AutoMapper.Mapper' from assembly 'AutoMapper, Version=1.1.0.188, Culture=neutral, PublicKeyToken=BE96CD2C38EF1005'.
There seems to be an open issue about this # CodePlex, but i thought that i'd ask if anyone has found any solutions to this?
As always, i'm more than happy to provide any additional info required!
AutoMapper uses Castle Dynamic Proxy which requires Reflection.Emit which is not supported on the phone.
If you want this you're going to need to look at building it all yourself. In terms of getting round the lack of reflection.Emit (if you really do need it) then you should look at using Mono.Cecil to provide this missing functionality.
Seems that automapper is working on silverlight edition so possible WP7/WP8 compatibility coming soon.
In the mean time there is a simple mapper library that you can use. It is very basic but probably meets most of your requirements for WP7 applications.
// Configure LazyMapper
Mapper.Create<SampleClass, SampleClassDto>();
// Perform mapping
var dto = Mapper.Map<SampleClass, SampleClassDto>(new SampleClass {
StringVal = "String1"});
Assert.AreEqual("String1",dto.StringVal);
Download at http://lazycowprojects.tumblr.com/LazyMapper