I can create a service reference in Visual Studio 2010 to an xsd. That reference downloads all the linked xsd files. However, I have 2 problems I'd like to see if there are solutions:
The URL for each xsd actually ends in .gx (e.g., http://mycompany.com/Schema1.gx). When Visual Studio imports the files, it renames them to .xsd, but in the xsd:import node, it keeps the original reference name with .gx, so my reference, once it's in Visual Studio is "not found or invalid"
for some of the xsd:import statements, the path to the referred-to .gx file is in another directory (e.g., schemaLocation="subDirectory1/Schema1.gx"). However, when they're imported, all xsd files are in the same directory in Visual Studio, but again, the xsd:import node is not modified to reflect the flatter structure.
Is there a solution to import these xsds in a valid way?
It is most likely a bug - the svcutil doesn't "refactor" the schemas. If you want a tool that handles this kind of work and more like it, this XML Schema refactoring tool should help. Download, install and create a new XML Schema Refactoring file (.xsr); add a new XML Schema collection; right click on the version 1.0, select [Import Schema Files...] command and follow the prompts. It can "slurp" online schemas, including ones referenced from, or embedded into, WSDL files, etc.
Related
When using Typescript in Visual Studio in a project with internal modules (namespaces) and using gulp to build, concat and minify the files, I have to maintain references to other files correctly using /// <reference path="..." /> to ensure that the concatenated files are ordered in respect to the their dependencies to avoid that files load before their dependencies.
In a larger project with many classes, it's cumbersome to keep all references up to date by looking at a specific file, traversing to it's dependencies in the solution explorer and drag them into the file to create a reference-tag.
However, both Visual Studio and Resharper are able to correctly identify the source file for a type as F12 immediately takes me to it. So my tooling knows very well where stuff is.
Is there a way for Visual Studio and/or Resharper to automatically maintain the references within a file, or at least to offer me a shortcut to automatically insert a reference for a type just like I can press F12 to open the file?
The only thing I could find so far were those two pages
http://msdn.microsoft.com/en-US/library/y4sy8216(v=vs.80).aspx
http://msdn.microsoft.com/en-US/library/y4sy8216(v=vs.90).aspx
Along with the respective "descriptions".
However, they are far from complete as is evidenced by the missing descriptions for elements underneath the Tool element.
So then I found the descriptions for VCProjectEngine in the VS installation folder:
C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.VCProjectEngine.xml
but it's unclear whether the names of the object properties is a 1:1 mapping to those inside the resulting .vcproj file?
Things appear to be a little more straightforward for newer VS versions (MSBuild based), but not completely.
There are none that describe the whole project file. The thing is that many tags work by convention, many tasks can be declared and named inline by simply calling out to the task assembly.
So even though for the basic structure a XSD exists, there is none that describes every possible way a project file can be setup not can you validate the project file without loading the tasks and have them validate their own snippets.
When I open up an xsd file that includes other xsd files, all of the included files are added to a section called "Unauthorized zone". Visual Studio highlights the xs:include element and gives the following error when trying to resolve the schemaLocation attribute:
Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
I've read the following blog post, but I'm not familiar enough with xsd yet to fully understand it.
Can anyone explain why this is happening or point me to a good resource that can help?
[Edit]
All of the xsd files that are to be included are in the Visual Studio project.
For me it worked after going to the properties of the XSD file and clicking on Unblock. i got this answer from How do I modify my settings to allow VS2010 to load 3rd party XSD files from the "Unauthorized Zone"?
Visual Studio caches XSD schemas at %VsInstallDir%\xml\Schemas with Target Namespace attribute (url of schema file) when you add them to your editor.
Blog post says that
The inclusion of Local.xsd in the “Unauthorized Zone” and the warnings in the error pane about not being able to resolve the schema location are an indication to the end user that the schema they were visiting attempted to bring in a schema from a zone that it is not authorized to access.
Reason the IO Permission error shows itself is your machine has no authority to download external xsd file(s) from the location.So there is no cache that Visual Studio might validate your other xsd files.
You should check your networking options so you may download those xsd files.While you can it means you have access to that location,so Visual Studio can cache them.If you're sure that you have access,you may also download those xsd files and put them Visual Studio's default schema location and indeed add them in editor.
Also check about cache here
Hope this helps
Myra
Need to do 2 things:
Unblock the xsd file, in windows do right click in properties a click unblock.
Go to visual studio, options, tools, text editor, xml, and check downloads dtd and schemas.
These warnings will disappear when you run Visual studio as administrator.
I want Intellisense support when writing App.config sections or XML configuration files for components like NHibernate, log4net, or Unity. What options do I have to get Visual Studio to find these files and load Intellisense?
(Assume we have the schema file.)
Yes it is possible to do this. You need to associate the schema with the document and the XML editor will then provide intellisense. The following links go over how to achieve this
http://msdn.microsoft.com/en-us/library/ms255811.aspx
http://msdn.microsoft.com/en-us/library/ms255815.aspx
Open your config file, under the properties window for your config file there is a section called 'Schemas', add your schema there.
I was mildly surprised recently to discover that my carefully crafted xml comments weren't showing up in intellisense for my colleagues. Having always used the associated assemblies with project references, I hadn't realised that you had to export the .xml document as well to access this information.
This led me to wondering how the .Net framework intellisense works. If I understand correctly, the .xml files must be hidden away somewhere in a special folder?
But my main question is about 'Goto definition' - if you goto definition on a .Net framework assembly, you get the info generated from metadata - but also with plenty of helpful comments - are these magically generated from Xml comments, or did someone have to write a macro + to convert them just for the build? Putting it differently: how can I get this effect for my assemblies?
Are your projects configured to generate the XML documentation? Just because you add the comments to the source code, the compiler won't generate the .xml file unless it's told to.
In the project properties page, go to the "Build" tab and look at the "Output" section. You should see a checkbox entry titled "XML documentation file". If textbox following that checkbox is empty you aren't generating the XML documentation file.
Once you get the XML documentation file generated, you should see your comments in the IntelliSense tooltips. If you include references to other projects as a project reference this should happen automatically. If you include references to assemblies, you need to ensure that the xml file is in the same location as the referenced assembly. (When you build, you should get xml files for all of the assemblies that have them in the bin/debug or bin/release folder respectively.)
For the .NET Framework assemblies themselves, the corresponding xml documentation files are installed as part of the Framework. For .NET 2.0, 3.0, or 3.5 the documentation files are located at C:\Windows\Microsoft.NET\Framework\v2.0.50727\en (assuming a default installation of the Framework). These files are used by both the IntelliSense tooltips and the "Go to Definition" functionality in Visual Studio in order to display this information. There is not any special processing that takes place or macros run in order to make this happen. The only information Visual Studio most likely uses is a combination of registry keys to determine the correct path to the documentation files.
While you probably could locate the xml documentation files for your own assemblies in the same folder, I would recommend against doing so as you then pollute the Framework installation with non-Framework related files.