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.
Related
I am trying the steps on this page. I have installed the wix binaries in a folder on my local machine.
So I got a wix installer project created by wix VS 2010 plugin. I can use the VS 2010 IDE to build it and generate the msi file, but I cannot do the same thing with Msbuild in the VS command prompt. When Msbuild try to compile, there is an error complaining the candle.exe cannot be found:
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'file:///C:\MyFolder\Wix\candle.exe' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
I am pretty sure the exe is at the right place because VS IDE can find it. I would like to know what am I missing for Msbuild?
Thank you!
I found answer from here: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Error-in-candle-during-build-td7385947.html.
Before unzip the binaries, right click on the zip file, select property and choose Unblock from the first tab. Then you unzip it as normal.
As per the page provided by you, the path entered in the lines of code will help the MSBuild script to identify the WIX binaries.
<PropertyGroup>
<WixToolPath>$(SourceCodeControlRoot)\wix\3.6.3220.0\</WixToolPath>
<WixTargetsPath>$(WixToolPath)Wix.targets</WixTargetsPath>
<WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
</PropertyGroup>
The important quote here goes like:
WixTargetsPath property value must be relative to the .wixproj project
file that uses it. The WixTasksPath property is used inside
wix.targets to load WixTasks.dll
The paths should be specified properly according to the folders where you unzipped your files. Otherwise there is a chance for this error to happen. Then also the project will be running fine from VS2010 since that is reffering the WIX binaries from the installed location of WIX. But, MSBuild will refer the values you provide in the above lines of code.
So, can you please provide values you are giving for WixToolPath, WixTargetsPath and WixTasksPath. As well the path to where you are unzipping the wix36-binaries.zip or wix37-binaries.zip.
These information may help in solving this issue and accordingly I will correct this answer as well.
Anyone can help us here - we have been having this error for several months and had many a stab to remove it, but we still havnt figured out why its there or how to remove it. How is this warning resolved or removed?
Warning 351 A custom tool 'GlobalResourceProxyGenerator' is associated
with file 'App_GlobalResources\GridLocalization.bg-BG.resx', but the
output of the custom tool was not found in the project. You may try
re-running the custom tool by right-clicking on the file in the
Solution Explorer and choosing Run Custom Tool.
After checking out the csproj file and discussing it in the group, we came up with the following answer:
When the resources were added to the project they were added using the wizard. This wizard added the designer files also, so for each reasource file there was also a .designer file.
This was seen as something that was not needed for the language specific resources and the designer files were deleted.
However the csproj files maintained the custom tool reference.
Deleting this reference (to "GlobalResourceProxyGenerator") for each of these resource files removed the issue.
The issue is that Visual Studio 2010 does not automatically remove this tool reference when the designer files are removed manually, creating this warning.
In my case this was caused by a <LastGenOutput> entry in the csproj file that referred to a non-existent file. Removing that line got rid of the warning.
In Visual Studio 2017 I had the same issue with the following error
Warning A custom tool 'ResXFileCodeGenerator' is associated with file <snip name>, but the output of the custom tool was not found in the project.
Removing the reference to
<Generator>ResXFileCodeGenerator</Generator> within the resource file declaration, fixed the issue.
In VS 2019, I also fixed the error:
Warning A custom tool 'ResXFileCodeGenerator' is associated with file , but the output of the custom tool was not found in the project.
By removing the reference to ResXFileCodeGenerator
found within the project's " .csproj" file!
I am trying to create a VISX extension for Visual Studio 2010 that contains a few project templates. These templates aren't very complex, but I want to expose some additional configuration for them during creation via a wizard. I have successfully set up my VISX package to deploy the templates to the directory structure I want in VS2010, but as soon as I try to configure and run a wizard, I receive an error when I create the template along the lines of:
Error: this template attempted to load component assembly
'My.Assembly, Version 1.0.0.0, Culture=neutral, PublicKeyToken=...
My current configuration is as follows:
All the projects live in the same solution.
The VISX project includes project references to the project containing the wizards and to each template.
Each template is built from a project template template (...confusing terminology).
They are added through the .vsixmanifest designer as content, referencing the projects.
Each .vstemplate file has a WizardExtension element pointing to the IWizard implementation and containing assembly.
The wizard assembly is signed.
The .vstemplate files point to their wizards like this:
<WizardExtension>
<Assembly>My.Assembly, Version=1.0.0.1, Culture=neutral, PublicKeyToken=a494da9e6e53f845, Custom=null
</Assembly>
<FullClassName>My.Assembly.Wizard</FullClassName>
</WizardExtension>
This, as far as I can tell, is how I'm supposed to do it. What exactly is going wrong? It looks like it can't find the assembly. Are there any other steps I need to take in order to get the assembly visible to the templates? The assembly is deployed to the extension folder when it is installed (I verified this), so it is at least making it out. Is there something special I need to do to the .vstemplate files to tell them to look in the extensions folder vs the GAC? Did I just miss something?
Note that I have found several pages on the internet stating that I have to GAC the assembly manually or with a script. However, few had my exact scenario (Project template templates being referenced by a VISX project, most examples are using a regular project exported via the project template wizard and having their packages dumped into the VISX folder structure). The only one I found that matched my scenario was an example from Microsoft. I tried to match that, but alas it still does not work. I tried relocating the project I downloaded to reference in this question but I cannot find it again, though.
Using scripts is how we've done this before, but I want to try and make things a little cleaner using VISX packages. I would like to avoid this, but if it's mandatory to script the VISX to install the template to GAC, I can do that.
When deploy the wizard based project template by VSIX Extension, it is better to use Short-Named assembly in .vstemplate. This can avoid the GAC deployment.
In your case, it should be:
<WizardExtension>
<Assembly>My.Assembly</Assembly>
<FullClassName>My.Assembly.Wizard</FullClassName>
</WizardExtension>
I am using VS2015 and faced this issue on and off. When I started building VSIX project with Wizard implementation, everything worked fine for sometime (4-6 weeks) and suddenly it stopped working. After a couple of weeks it would start working again and stop working without notice. Took me long time to find a workaround (still don't know why it suddenly stops).
This is how my VSIX project is built
I have VSIX project, project template and Wizard implementation in
the same solution.
VSIX and Wizard implementation are in the same project.
Added VSIX project dll and project template as Assets in VSIX project source.extension.vsixmanifest.
Project template *.vstemplate has Wizard section which refers to VSIX project with strong name:
<<<<<<<<<<<<<<<<<<<<<<
<WizardExtension>
<Assembly>Test.Template.TemplateInstallerWizard, Version=1.0.0.0, Culture=neutral, PublicKeyToken=30ab381f68dc4f5e</Assembly>
<FullClassName>Test.Template.TemplateInstallerWizard.WizardImplementation</FullClassName>
</WizardExtension>
None of these worked for me
Uninstalled extension from VS regular instance via Tools->Extensions
and Updates..
Uninstalled extension from VS experimental instance by
launching VS exp instance from VS2015 command prompt as Administrator:
devenv.exe /rootsuffix exp
and then uninstalling the extension via Tools->Extensions and Updates..
Using short named assembly as explained by #Ethan Wu.
Installing templates via this command from VS2015 command prompt launched as administrator:
devenv /installvstemplates
Rebooting VS2015, my machine several times during this process.
This is what worked for me (thanks to #Ethan Wu)
Remove certificate from VSIX project.
Remove strong name from Project Template *.vstemplate
file
<WizardExtension>
<Assembly>Test.Template.TemplateInstallerWizard, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null</Assembly>
<FullClassName>Test.Template.TemplateInstallerWizard.WizardImplementation
Clean and build the project.
Remove extension from VS regular instance and close VS2015 (not
absolutely required)
Install the extension.
Open new VS2015 instance and try to create the project with
wizard.
Couple of things to help debug
When VSIX project is build, in bin\debug folder a file is
created -extension.vsixmanifest which has the assets type.
Look for Asset Type="Microsoft.VisualStudio.Assembly":
AssemblyName value is what is expected in project template's
*.vstemplate WizardExtension section - they should match exactly.
After installing extension, go to VS2015 extension location on
local box:
%appdata%\..\Local\Microsoft\VisualStudio\14.0\Extensions\<some_temp_folder>
open extension.vsixmanifest to ensure that Asset
Type="Microsoft.VisualStudio.Assembly" AssemblyName value is
correctly populated. If required, you can change this value and
restart VS2015 to make this in effect.
Hope this will help someone and save tons of time as there is very little help on Wizard and custom project templates.
Thanks,
RDV
I run into the same problem, but mine came to light when I updated the AssemblyVersion of my wizard project. I checked and the versions in the manifest files matched as they should.
I simply went into C:\Users\Albert\AppData\Local\Microsoft\VisualStudio\16.0_c340331cExp\Extensions, found my extension and deleted it there. Now it works again.
(Note that I did find a few others since I've since changed the company name etc, in the AssemblyInfo file, so it could be the old ones laying around that also caused this)
I have a .edmx file and I can't open it with the designer. It just opens as plain XML file. When I try to "run custom tool" on it, then it says that:
The custom tool 'EntityModelCodeGenerator' failed. Could not load file or assembly 'Microsoft.Data.Tools.VSXmlDesignerBase, Version=10.0.0.0, ...' or one of its dependencies. The system cannot find the file specified.
And indeed, I don't have this file on my system. I've tried copying it to my machine, but then I get:
An error occurred loading the Entity Data Model Tools Package.
I have VS2010 SP1 Professional installed.
I've tried repairing and reinstalling VS and SP1, and installing some entity packages/patches (I don't remember the exact names of them), but that didn't help. What else can I try?
It appears that my installation package didn't have the L2E tools.
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.