By default all I get in intellisense are the functions and its signature. I would prefer if I could also get documentation with the intellisense. I realise that I am supposed to place an xml file that contains this documentation along with my dll.
From where can I get this is file? Or is there some other way for me to achieve this?
For the immediate future, there's no way to get the XML documentation short of grabbing the Structuremap source and building it yourself.
As for why that's not included with the distribution, I'm not sure. My only guess is that back when xml-based configuration with SM was more prevalent, Jeremy was concerned about confusion between StructureMap.xml the intellisense file, and StructureMap.xml the configuration file.
That's pure speculation however. For the real scoop you'd have to post on the SM-mailing list. Regardless, for the time being, you have to roll your own from the source. I've done this as well for the same reason, and it wasn't too painful.
-Scott
Edit - Instructions for doing this follow.
Using your favorite SVN client (if you don't have one, I recommend TortoiseSVN) grab the latest from https://structuremap.svn.sourceforge.net/svnroot/structuremap/trunk/ . If you want the same bits that are in 2.5.3, I think you'll want revision 234. Otherwise, just grab the head and build from that. (If you aren't familiar with SVN, find a tutorial that explains what I'm talking about)
Open up the StructureMap solution in Visual Studio (under the Source subdirectory). Right click the StructureMap project, Go to Properties > Build and ensure the option for XML output documentation is checked.
Build and enjoy.
Related
I just upgraded to the newest version of Pharo Smalltalk. Before doing so, I "File-outed" a package from my old version called My-Pharo - a package I use for various configurations and customizations of Pharo itself, most notably a class to put back "Workspace" in the main menu. I then "File-ined/Installed" the file into my new version.
When I checked the SystemBrowser, I had correctly gotten the My-Pharo package, but I'd also picked up a package called My-Pharo-Manifest... I see My-Pharo-Manifest actually is part of my File-Out, and seems to contain the package-comment for My-Pharo .
What is this manifest, what is it's purpose, and how should it be used? Is there something I can/should do to "merge" the manifest (ie. the comment) back into the My-Pharo class? Should I move the content of My-Pharo-Manifest somewhere else? ...Or is my best bet to simply delete the Manifest-package, and re-write the package-comment for My-Pharo?
I'm not a seasoned Pharo developer, I use it just time to time. I'll try to answer your question from the source code. For more detailed answer you would have to get it from the ones that are actually do the development of Pharo.
What is manifest?
Manifest contains package metadata.
what is it's purpose?
The purpose is to make life easier for the SmallLint (Smalltalk Code Critics). It is there for its speedup, because without the manifest the SmallLint would have to check the rule results all the time. Package metadata helps in managing false positives and/or TODOs.
packages: If you check for the where is the #hasPackageNamed: used, you will find out that it is at SmallLintManifestChecker>>manifestBuilderOfPackage:.
methods: if you search for #hasManifestFor: SmallLintManifestChecker>>manifestBuilderOfMethod:
Is there something I can/should do to "merge" the manifest (ie. the
comment) back into the My-Pharo class? Should I move the content of
My-Pharo-Manifest somewhere else?
I would just leave it be. It helps the SmallLint to do its job.
I have a custom XML format that links to Java resources. For the sake of simplicity let's assume my XML file would look like this:
<root>
<java-class>my.fully.qualified.class.name</java-class>
</root>
Eventually my references will be somewhat more complicated. It will not contain the fully qualified class name directly and I will need some logic to resolve the correct class, but I want to keep the example as simple as possible here.
Now I want it to be possible to Strg+Click on the element's text and want IntelliJ to carry me to the .java file, just like it is possible in Spring-XML files. In the IDEA Plugin Development FAQ there is a link called "How do I add custom references to Java elements in XML files?" which so much sounds like exactly what I need. Unfortunately it links to a discussion where someone is more or less done implementing something like this, having some minor problems. Nevertheless I understood that I probably need to write an implementation of the interface com.intellij.psi.PsiReference. Googling for "PsiReference" and "IntelliJ" or "IDEA" unfortunately did not bring up any tutorials on how to use it, but I found the class XmlValueReference which sounds useful. Yet again googling for "XmlValueReference" did not turn up anything useful on how to use the class. At least the PSI Cookbook tells me that I can find the Java class by using JavaPsiFacade.findClass(). I'd be thankful for any tutorials, hints and the like, that tell the correct usage.
The above linked discussion mentions that I need to call registry.registerReferenceProvider(XmlTag.class, provider) in order to register my provider once I eventually managed to implement it, but of which type is "registry" and where do I get it from?
First of all, here's a nice tutorial that came up a few days ago, which explains the basics of IntelliJ plugin development (you should take a look at the section Reference Contributor).
You will likely have to define your own PsiReferenceContributor, which will be referenced in your plugin.xml like this:
<psi.referenceContributor implementation="com.yourplugin.YourReferenceContributor"/>
In your reference contributor, there's a method registerReferenceProviders(PsiReferenceRegistrar) where you will be able to call registry.registerReferenceProvider(XmlTag.class, provider).
Finally, in your instance of PsiReferenceProvider, you will have to test the tag name to filter out tags which don't contain class references, then find the right Java class using JavaPsiFacade.findClass().
From my experience, the best place to get help regarding IntelliJ plugin development is JetBrains' forums.
I'm working with gendarme for .net called by Sonar (launched by Jenkins).
I've a lot of AvoidVisibleFieldsRule violations. The main violations are found in the generated files. As I can't do anything on it, i would like to exclude *.designer.cs from the scan.
I can't find a way to do that. There is a properties in Sonar to exclude generated files but it doesn't seem to be applied for gendarme.
Is there a way to do such a thing ?
Thanks for all
Gendarme expects you provide an ignore list,
http://www.mono-project.com/Gendarme.FAQ
https://github.com/mono/mono-tools/blob/master/gendarme/self-test.ignore
The ignore file format is bit of weird, but you can learn it by experiments.
Indeed that is actually not normal at all. Generated code is excluded by the plugin with the standard configuration. What version of the C# plugins are you using ?
Anyway, the configuration property you can try is "sonar.exclusions" (see http://docs.codehaus.org/display/SONAR/Advanced+parameters).
If you do not solve your problem right away, the best thing would be to drop a mail to the user mailing list (see http://www.sonarsource.org/support/support/) and send the verbose output of your build. To get this output simply add "-X" to the command line.
Hope it helps
I have a library I wrote with a structure like this:
SolutionA\
--Source\
--Core\
--Tests\
--Tools\
--TestFramework\
--MockTool\
SolutionA.sln
I want to include this as a submodule for SolutionB. If I use this entire structure as a submodule, it would get a bunch of stuff that SolutionB doesn't care about; it doesn't care about SolutionA.sln; it doesn't care about Tests\; it doesn't care about Tools\. Really, SolutionB only cares about Core\.
It looks like I need a separate repository for Core\. So is it usual practice to have two repositories for .NET solutions whose source is used by other solutions? One for only the (non-test) code itself (plus needed libraries), and one for the test tools and solution file?
Solutions are simply containers for one or more projects; which may fall under the same "solution" folder or somewhere externally.
If you have a project, in this case "Core" then you can reference that project source directly from one or more solutions. In this case, SolutionA and SolutionB.
The extraneous stuff like Tests\, TestFramework\, MockTool\, etc, unless required by Core, don't have to be included in your other solution.
Make sense?
You COULD solve this with git-submodules (your tag leads me top believe that you use git). I don't know what the "usual practice" for stuff like this is.
As reply to my question about how to deal with submodules, dirk proposed to use nuget (the package manager for the .NET Framework. see http://nuget.org) to solve a related problem. Seems to be a good fit for you, as you would get controlled updates for the dll, dependency management if you need it and (at least at the client side) good tool support.
Scott Hanselmann has a good article how to integrate nuget into Continous Integration.
I want to remove AssemblyInfo.cpp, because of some metadata errors that sometimes come up.
Is AssemblyInfo.cpp useful for anything? Or can it be removed without any problem?
I've discovered one distinction for this file: it has to do with values reported under calls to Assembly.GetReferencedAssemblies. I was working on tracking version numbers of our binaries from our SVN repository by embedding the revision numbers into them. Initially I too was updating AssemblyInfo.cpp and found nothing reported in the file property details tab for the binary. It seemed this file did nothing for me in terms of updating those details, which was not the case with similar updates to a csproj's AssemblyInfo.cs. Why the difference right?
Now in one such csproj we happen to reference a vcxproj and that csproj dumps to a log the versions of all its referenced assemblies using the .NET Assembly.GetReferencedAssemblies method. What I discovered was that the number that was being reported in that log was not the vcxproj's version as given by the VS_VERSIONINFO resource I added (which does get the version details into the file properties details tab). Instead the number reported was actually matching that defined in the AssemblyInfo.cpp.
So for vcxproj files it looks like VS_VERSIONINFO is capable of updating the contents you find under the file properties details tab but AssemblyInfo.cpp is capable of exposing the version to GetReferencedAssemblies. In C# these two areas of reporting seem to be unified. Maybe there's a way to direct AssemblyInfo.cpp to propagate into the file details in some fashion, but what I'm going to wind up doing is duplicating the build info to both locations in a prebuild step. Maybe someone can find a better approach.
So far I never had the AssemblyInfo.cpp in my managed c++ dlls, so I don't think it is necessary.
(I just added the file to have version information for my c++ dlls).
Why not just fix the errors? On that note, what errors are you getting?
This file provides information such as a version number which is definitely needed in order to use the assembly you have built.