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.
Related
I want to override methods of LayoutImpl in Liferay 7. I tried with service wrapper but there is no option for this class in the Service Name category.
How can I achieve that? Do I need ModelListener for this?
Hint: A service wrapper is used to wrap services. Services in Liferay are usually named ...Service, like LayoutLocalService.
Conclusion: The class LayoutImpl is no service - thats why you can't wrap it with a service wrapper.
You could wrap LayoutLocalService in a service wrapper, wrap the return values in your LayoutWrapper and unwrap the parameters. But that is troublesome and will prevent Liferay upgrades.
If you want to override LayoutImpl for fixing bugs - you should use an Ext Plugin for that.
A ModelListener can only change the content during updates of an article, not the implementation - I don't think that this will help here.
I created service wrapper for UserLocalServiceImpl and declared a new method inside the service wrapper. But when I explicitly call that method using UserLocalServiceUtil the compiler could not resolve this method. So, kindly help me and tell how to override UserLocalServiceImpl so that I can define new methods inside it. Thanx in advance..
This doesn't work. You'd change the interface of Liferay's published API and basically be incompatible with any other plugin that assumes Liferay's API.
While you technically have access to all of Liferay's source code and can build a modified version of Liferay, introducing this change, it would mean that no marketplace plugin (that uses UserLocalService) would be compatible with your customized version. Any OSGi component can hook into Liferay and get into the callstack for the published API, no OSGi plugin can extend a published interface so that the original interface then has more methods than Liferay's published API.
The best thing you can do if you rely on a separate function call: Create your custom service that makes calls to UserLocalService.
Further more, in Liferay 7 you shouldn't use UserLocalServiceUtil any more, rather get the service dependency properly injected through a #Reference annotation. The *LocalServiceUtil classes are there purely for backwards compatibility and to be used only from *.WAR style plugins.
You can do
UserLocalServiceUtil.getService()
and then cast the result to your custom wrapper type. Then you should be able to call the new method.
Is there any alternative to achieving serialising and deserialising of objects in Xamarin.iOS (Monotouch) using protobuf-net other than this method:
http://www.frictionpointstudios.com/blog/2011/3/31/using-protobuf-net-serialization-in-unity-iphone.html
Reading around some people claim they have managed it (without giving evidence), but my understanding is that [iOS JIT==NO] so does not quite make sense.
If the only possible solution is to fully AOT all relevant classes what might a suitable pre/post-build event command line be to perform this AOT for any relevant assemblies automatically?
I've heard a good number of people have success via that route, but I too can't give documented evidence.
That method is a bit out of date - I've simplified a few steps; there is a standalone pre-compile tool that should work:
create a project/assembly for the DTOs that you want to serialize that references the appropriate version of protobuf-net; presumably CoreOnly/ios, ideally with that dll set to copy into the output directory (it just makes life easier)
run
precompile "SomePath/YourDto.dll" -t:MySerializer -o:MySerializer.dll
(maybe with a mono before that to get mono to host the exe)
this should resolve the framework and compile a MySerializer.dll that you can reference, which involves zero JIT (MySerializer.dll will reference your dto dll and the version of protobuf-net that your dto dll referenced)
now reference your dto dll, the serializer dll, and the protobuf-net dll, and it should all work just by using new MySerializer().Serialize(...)
when you compile your solution, the projects should all AOT nicely
I'll be happy to offer guidance, but currently I am mac-less, so I can't check right now. If you get any problems let me know. If it can't resolve the framework, you can add -f:{path to the framework assemblies} to give it a clue.
I got protobuf-net 2 working on Xamarin-iOS by using the netstandard1.0 dll. You can get this dll by extracting the nuget package. No changes were needed.
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.
I have been trying to get Moq (or rather Castle.Core) to create proxies for my internal types.
The following (when added to my project under test), allows things to work:
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]
However this (more secure version) does not:
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2, PublicKey=002400000480000094000000060200000024000052534131000400000100010077f5e87030dadccce6902c6adab7a987bd69cb5819991531f560785eacfc89b6fcddf6bb2a00743a7194e454c0273447fc6eec36474ba8e5a3823147d214298e4f9a631b1afee1a51ffeae4672d498f14b000e3d321453cdd8ac064de7e1cf4d222b7e81f54d4fd46725370d702a05b48738cc29d09228f1aa722ae1a9ca02fb")]
Note: the public key here differs to that documented here, I re-checked the public key of the Castle.Core.dll that ships with the current Nuget version of Moq.
Do I still have the wrong key?
[EDIT]
I have noticed the full Moq download from the official site (rather than Nuget) contains a NET40-RequiresCastle folder with a smaller dll, which implies that the Castle.Core code has been included in the default Moq.dll I guess.
I was looking at the Castle.Core.dll they provide for Silverlight and assuming they'd have used the same version throughout?
I know this is old, but for anyone who stumbles across this, I was having a versioning issue with Pex and Moq at one point, and wound up finding the most direct and useful approach to be the Strong Name Tool. That is, I found opened a Visual Studio command prompt and used "sn -Tp ThirdPartyAssembly.dll" to query it for the key directly. This proved a lot more efficient than perusing the internet looking for different, documented public keys to try out.