I am having trouble finding faked Thread.Sleep in mscorlib.fakes library.
I am following direction at http://www.codewrecks.com/blog/index.php/2012/04/27/using-shims-in-visual-studio-11-to-test-untestable-code/
http://msdn.microsoft.com/en-us/library/d00bd51t(v=vs.100).aspx shows Thread.Sleep is in mscorlib so I added its fake but System.Threading.Fakes namespace doesn't contain ShimThread nor StubThread.
Thread is a sealed class but VS fake framework should be able to fake static method in sealed class.
This is very much possible. By default Fakes framework doesn't generate shims for most types (including types in System.Threading namespace) of mscorlib because Fakes framework itself makes use of mscorlib. So only a few of the types are shimmed,
However, you can configure this behavior by changing the mscorlib.fakes file added in your project.
<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
<Assembly Name="mscorlib" Version="4.0.0.0"/>
<ShimGeneration>
<Add Namespace="System.Threading!"/>
</ShimGeneration>
</Fakes>
Now build the test project and you can see shims for types in the System.Threading namespace, including ShimThread.SleepInt32.
Read more about the .fakes xml file on this page
This is because the Shim framework cannot fake all .Net BCL classes in mscrolib and System, see: MSDN.
Unfortunately I couldn't find a list of types that aren't supported. But it seems, primarily types that are not pure CLR classes or need OS functionality (Thread, FileSystemWatcher, ...) are not supported at this time.
Related
I'm trying to create a custom annotation processor that generates code at compilation time (as hibernate-jpamodelgen does). I've looked in the web, and I find custom annotation processors that works with maven, but do nothing when added to the Annotation Processing > Factory Path option. How could I create a processor compatible in this way? I have not found a tutorial that works.
My idea is to, for example, annotate an entity to generate automatically a base DTO, a base mapper, etc that can be extended to use in the final code.
Thank you all
OK, Already found out the problem. The tutorial I hda found out dint't specified that, in order to the compiler to be able to apply the annotation processor, there must be a META-INF/services/javax.annotation.processing.Processor file that contains the qualified class name of the processor (or processors).
I created the file pointing to my processor class, generated the jar and added it to Annotation Processing > Factory Path and all worked correctly.
Just be careful to keep the order of the processors correctly (for example, hibernate model generator claims the classes, so no more generation will be made after it), and change the jar file name each time you want to replace the library (it seems eclipse keeps a cache). These two things have given me a good headache.
Thanks all
"The ambiguity, is in the box" - Monty Python.
Autofac is having a problem resolving an interface. See attached solution.
The Interface, IAmbiguous, is defined in project ACommon. It is implemented in project AInjectable. The AInjectable project does not / cannot reference ACommon. The AInjectable project defines IAmbiguous as an existing item brought in with a file link.
The UI project calls ACommon Inject and attempts to register the AInjectable assembly. IAmbiguous is not ambiguous initially but after a builder.RegisterAssemblyTypes command it becomes "ambiguous in the namespace." There is no error thrown when the container is built but the registration is not there.
Registration can be done "AsImplementedInterfaces" if Named and Keyed is not used. But then there is no way to Resolve the registration because the service IAmbiguous is "ambiguous in the namespace."
This question was double-posted as an issue on Autofac. It is not an Autofac problem. I will copy/paste the answer from the issue in here; for future readers, if you want to see the repro solution, go check out the full issue
What you're doing by including the same interface in two different assemblies isn't something you should be doing. Note that by doing that, your AInjectable class is not implementing the interface from the ACommon project. It's implementing a different but identically named interface.
This sort of thing is a problem - having the same type (interface, class, whatever) name in two different assemblies. We even had a problem (#782) where we had a System.SerializableAttribute in Autofac as a shim for .NET Core. You really just can't do that.
You'll also see the same thing if you try to make a static extension method class that has the same namespace and name as some other static extension method class. Ambiguous references.
Without doing Reflection.Emit style code generation, you won't be able to declare an interface in one assembly ("Assembly A") and implement that interface in a different assembly ("Assembly B") without having Assembly B reference Assembly A. That's just how .NET works. What you're seeing is a manifestation of that when you use Autofac, but it's not caused by Autofac. It's caused by you doing something you shouldn't be doing in .NET.
The fix is to define your interfaces in a separate assembly that everyone implementing the interfaces can reference. (Or you can try to dynamically generate code using Reflection.Emit or Roslyn or something, but that's waaaay harder.)
I have a Prism project with several modules. Using EF code first for generating the database.
I am trying to build the context using partial class. For each module will have its partial class context (one context whole solution).
I am using the same namespace for each module to create the context. However, when initializing the database, only the tables defined in the main module is created, but not the others.
Is there anything I could look for or is there a better way? Tks.
All parts of partial class must be in the same assembly (in your case probably in the same module) because it is just syntactic sugar to divide single file (class) into multiple parts but these parts are concatenated during build. Partial classes will not help you to achieve modularity (if you expect to add or remove modules to deployed application).
I'm generating java code based on various WSDL's. We have a different WSDL for every new version of the WebService that we release, each with its own namespace.
The thing is that normally the changes are minimal from one release to another, but I want to keep classes divided by namespace.
Is there a way to configure JAXB so that the auto generated classes implement a single interface/extend a single class, so I can refer to either of them without changing my code?
Dummy example:
WebService method: listScripts(ResultSize size);
Auto generated classes:
com.test.ws1.ResultSize
com.test.ws2.ResultSize
Both classes are exactly the same. Is there a way to arrange them in a class hierarchy so my code is isolated from changes in version numbers? i.e. a com.test.ResultSize interface implemented by both classes?
XJC has an extension for this purpose
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
jaxb:extensionBindingPrefixes="xjc"
jaxb:version="2.0">
<xs:annotation>
<xs:appinfo>
<jaxb:globalBindings>
<xjc:superClass name="com.mycompany.xml.UserRootObject"/>
</jaxb:globalBindings>
</xs:appinfo>
</xs:annotation>
.
.
.
</xs:schema>
For more information see:
http://jaxb.java.net/nonav/2.0.2/docs/vendorCustomizations.html
The schema annotations can also be supplied via an external bindings file. For an example see:
How do you customize how JAXB generates plural method names?
It turned out that I can use a plugin provided in the JAXB2 Basics package:
Inheritance plugin
With this plugin I can specify different super classes for my generated ones, although I couldn't make the auto generated enums to implement a given interface.
To use it in Maven it was a pain (I'm generating classes from a WSDL, not using JAXB directly), so I switched to an external Ant task as specified in this blog
I am looking for information to which PRIMS/MVVM ddls I have to reference to in my project to have available Prism/MVVM functionality for handling Commands. I plan to use only this part of the frameworks.
Regards,
Wojtek
If you only want commanding support I would suggest to completely avoid Prism and that way you will reduce the size of your .xap file.
I would suggest you to look at the code (either in Reflector or open Prism's source) and copy to your project all the files in "Microsoft.Practices.Composite.Presentation.Commands" namespace in the "Microsoft.Practices.Composite.Presentation" assembly. You can ignore CompositeCommand.
If you prefer to reference the assembly, go with "Microsoft.Practices.Composite.Presentation". If you only use commands you won't need other assemblies. The compiler will tell you in case start using other classes from that assembly that depend on another one. The other two dependencies for this assembly (for classes other than commands) are "Microsoft.Practices.Composite" and "Microsot.Practices.ServiceLocation".