I have a pretty simple form that I am wanting to localize (I actually have quite a few in this project, they all have the same problem). When I set the form property Localizable to true Visual Studio generates a .resx file with the form name (as you would expect). The problem though is that it's adding all sorts of things to the .resx file that nothing else can open (eg WinRes, ResEx, Simple Resx Editor, RESX Editor etc).
The error I get is:
ResX file Type System.Drawing.Point, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a the data at line 125, position 4 cannot be located.
Line 127, position 5. cannot be parsed.
Line 124 to 127 is:
<assembly alias="System.Drawing" name="System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<data name="lblUsername.Location" type="System.Drawing.Point, System.Drawing">
<value>26, 24</value>
</data>
Now I'm assuming that Visual Studio is adding this so that I can move buttons etc around depending on the language (I don't need or want this ability). However, it throws the above error in every editor other than Visual Studio.
The only extensions that I have installed (according to the Extension Manager) are:
Highlight all occurrences of selected word
Microsoft Ribbon for WPF (which I'm not using in this project)
Add-in manager shows no Add-ins.
Edit:
After digging around and manually editing the .resx file, the problem is actually with line 124 <assembly alias="System.Drawing" name="System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> specifically with Version=4.0.0.0.
If I set this to Version=2.0.0.0 then everything works, both in Visual Studio, and in all the external programs. The problem with this though is that if I edit anything within Visual Studio it will reset it back to Version=4.0.0.0.
For the time being I am going to set the Target Framework to .NET Framework 3.5 Client Profile so that Visual Studio doesn't override the version. This is a workaround and means that I can't use .NET 4.0 features.
Am I right in guessing that there's either a bug in the .NET Framework, or every single .resx editor out there (including Microsoft's).
Edit 2:
It turned out that when I was trying to use Microsoft's WinRes.exe tool I was actually launching the .NET Framework 3.5 version, since the .NET Framework 4.0 version doesn't get installed.
I had to install the .NET Framework 4.0 SDK from http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/winsdk_web.exe and I was then able to edit the .resx files with WinRes.exe 4.0
Visual Studio creates correct *.resx files. The problem is, tools that you are attempting to use were created for previous version of the specification. That's why your workaround works.
Please check if there are no newer versions or patches to localization tools you are using.
Sometimes in specific cases the windows forms designer crashes during validating the form with the *.resx files.
Controls where a DataSource was attached are affected from this behavior. In my case I got some DataSets as DataSource for Grids, Combos...
So I have opened the Designer and it't telling me it cannot open due a problem with a control named: blabla
after checking the designer-file I found out nothing is wrong with the control it's just the *.resx file pointing to a wrong source, because I refactored the DataSet. So the *.resx has not updated due this refactoring.
I opened the *.resx file and simply searched for the identifier of the control and found a Base64 encoded code. Deleting the value inside the block without deleting the surround tags will resolve the problem for this control as the windows forms designer will automatically refresh and readd the missing content to the *.resx file.
In the .resx, locate the first line of the base64 encoded string. The end should be "j00LjAuMC4w" (meaning .net 4.0). Try changing that to "j0yLjAuMC4w" (meaning .net 2.0). Worked for me. Thanks to Luis Mack at http://connect.microsoft.com/VisualStudio/feedback/details/532584/error-when-compiling-resx-file-seems-related-to-beta2-bug-5252020#
This error is presented when the compiler lost the reference of some object or when the you have changed a important property of this object, for example if you have a Grid on the form all setup (this means that you are using a DataSet as your data source to fulfill your grid), and you change the name of your DataSet VS lost this link, he will bring you this message.
i just deleted thease lines in my .RESX file
<assembly alias="System.Windows.Forms" name="System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken="" />
Related
I'm writing a Visual Studio extension which depends on EntityFramework 5.0.0.0. I included EntityFramework in my project. When I install my extension, my extension's DLL appears in VS extensions folder, and EntityFramework.dll appears with it as well.
However, when I run my Extension in Visual Studio 2013 (update 5), it can't load EntityFramework: System.IO.FileNotFoundException: Could not load file or assembly 'EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.
Looking in Process Monitor, I saw that when I run my extension, VS2013 tries to load EntityFramework from a different path, which has it in a different version - 4.2. I'd expect VS2013 to continue to search for EntityFramework, and find it in my extension's folder, like it does for other dlls included in my extension, but it doesn't.
In VS2015, VS does manage to load EntityFramework 5.0.0.0, but it does so also from yet another different path.
Why doesn't VS2013 continue to search for EntityFramework in my extension's folder?
You need to specify a ProvideCodeBase attribute to specify that your extra assemblies should be loaded. "Sometimes" you get lucky and it finds something else, but that's never guaranteed to work. You can see a few examples of that being used here.
How can I resolve these errors:
Loading the include file 'EF.Utility.CS.ttinclude' returned a null or empty string.
Value does not fall within the expected range.
Tools Used: VS 2012, Entity Framework 5.0.0, T4MVCExtensions 3.5.0, .NET Framework 4.5
I've been using EF and T4 templates in a project within a large MVC solution without incident. Now, when I right-click on the edmx diagram, EF responds with the message: Value does not fall within the expected range. When I compile the EF project it responds with these messages:
Loading the include file 'EF.Utility.CS.ttinclude' returned a null or empty string. The transformation will not be run. C:\Projects\NSAForms\NSAForms\NSAFormsEDM\NSAFormsEntities.tt
Failed to resolve include text for file:C:\Projects\NSAForms\NSAForms\NSAFormsEDM\EF.Utility.CS.ttinclude C:\Projects\NSAForms\NSAForms\NSAFormsEDM\NSAFormsEntities.tt
Every table in the database has a primary key. I'm struck by how suddenly this issue appeared. Does anyone have some suggestions how to resolve this issue?
Thanks in advance,
Arnold
I had very similar issue and I tried with VS2012 and VS2013.
After reinstalling Entity Framework 6 Tools for Visual Studio 2012
http://www.microsoft.com/en-us/download/confirmation.aspx?id=40762
every thing went back to normal.
In VS 2012, the EF.Utility.CS.ttinclude file will only be installed if the Microsoft Web Developer Tools or Microsoft SQL Server Data Tools component is selected.
Reinstalling Entity Framework 6 Tools for Visual Studio 2012 http://www.microsoft.com/en-us/download/confirmation.aspx?id=40762 work for me
For VS2017, I ended up adding EF6.Utility.CS.ttinclude to model's folder. This resolved my issue with MySql and EF.
File can be found: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Entity Framework Tools\Templates\Includes\EF6.Utility.CS.ttinclude
UPDATE To avoid doing the above, removing the entities completely then adding back in fixed the issue.
Had this issue with a recent install of VS2017 Enterprise after already having this functionality working in Professional.
The solution for me was to:
Open the Visual Studio Installer program and "Modify" my Enterprise installation.
Select "ASP.NET and web development" under the Web & Cloud section
Click "Modify" in bottom right
It's probably worth noting that I already had EF6 installed and did not need to re-install it to get this to work.
After completing those steps and firing up Visual Studio, the error went away and I was able to generate my classes successfully. Hope this helps!
Visual Studio 2017
was getting the same error but only in a test project. after reviewing the test project and the other project successfully referencing that file i found that adding the following to the app.config of the failing project resolved my issue
<configSections>
<!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</configSections>
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
<parameters>
<parameter value="mssqllocaldb" />
</parameters>
</defaultConnectionFactory>
<connectionStrings>
All of the above solutions did not work for me so I created a new project to see if the problem persists but the error did not occur in the newly created project. I then compared the project with the old backup to check recent changes made and found the problem. I recently had upgraded a package Clarius.TransformOnBuild to more recent version after downgrading the package the error went away.
In my case the issue was caused by a bizarre folder name (with %20 instead of spaces). I just made a directory junction to the same folder with spaces instead of %20 and it solved the issue.
Here is the PowerShell command I used to make the junction:
cd "c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\Extensions\Microsoft\"
mklink /j "Entity Framework Tools" "Entity%20Framework%20Tools"
Junction created for Entity Framework Tools <<===>> Entity%20Framework%20Tools
You can then use ls look at the directory contents, and you should see these two lines (edited for brevity):
Mode LastWriteTime Length Name
---- ------------- ------ ----
...
d----l 2/27/2019 9:57 AM Entity Framework Tools
d----- 2/26/2019 12:24 PM Entity%20Framework%20Tools
...
Under Mode, the l indicates that it is a "link" (aka junction), and the d indicates it's a directory. By making a junction instead of renaming the folder, you can be sure that both directory names will always work.
We have a WinForms application, targeting .NET 3.5.
Loading it up into VS2010 works fine, editing form layouts using the forms designer is fine initially, then we compile and run.
However, after that, pretty much any change to the layout of a form (sometimes just a solution rebuild) will break the designer.
The error we get is:
Could not load file or assembly 'OurControls, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
system cannot find the file specified.
Restarting VS2010 and reloading the solution will cure it, but only for a couple of edits before it recurs.
The project referred to in the message contains a bunch of home-grown controls that we use in the application. It's as if a Rebuild Solution causes VS lose its ability to reference it - but as I say, it has no problem on initial load.
We never had this with VS2008, and the solution is a straight upgrade from then.
Any suggestions would be greatly appreciated.. it's not yet practical to migrate to .NET 4, unfortunately, or to WPF!
Edit:
The folder structure is as follows:
Solution Folder
. Projects folder
.. Project A
.. Project B etc
The startup project, containing the forms, is in one of the folders A, B etc. The OurControls that it can't find, is one of the others at that level.
On initially opening the solution, all projects load correctly, and there are no errors or reference warnings.
On initial rebuild after opening the solution, all the project folders get their respective DLLs correctly.
A 'Clean Solution' does not solve the problem.
It's a VS2010 bug, see
https://connect.microsoft.com/VisualStudio/feedback/details/709080/after-working-for-a-while-vs-designer-stops-to-regnize-types-and-does-not-allow-designing-winforms#.
You could sending them a dump file when it happens , since it's easy for me to reproduce/send dump files to MS.
Not a fix, but in Visual Studio 2010 I've found out that the quickest way to get the form designer back on track is unload/reload the project where the form is in. Don't know if it always helps, but it is quicker than restarting visual studio.
Let's see if VS 2012 is better.
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.
Every time i build, or publish, a web-site, Visual Studio attempts to check out the web.config file so that it can add numerous assemblies that are not required.
In other words:
web.config before:
<configuration>
<system.web>
<compilation>
<assemblies>
</assemblies>
</compilation>
</system.web>
</configuration>
web.config after:
<configuration>
<system.web>
<compilation>
<assemblies>
<add assembly="Microsoft.ReportViewer.Common... />
<add assembly="Microsoft.ReportViewer.WinForms... />
<add assembly="System.DirectoryServices... />
<add assembly="System.Windows.Forms... />
<add assembly="ADODB... />
<add assembly="System.Management... />
<add assembly="System.Data.OracleClient... />
<add assembly="Microsoft.Build.Utilities... />
<add assembly="Microsoft.ReportViewer.ProcessingObjectModel... />
<add assembly="System.Design... />
<add assembly="Microsoft.Build.Framework... />
</assemblies>
</compilation>
</system.web>
</configuration>
None of these assemblies are required, and most don't exist on the target test, or production, servers.
i keep deleting them every time i build, but it's getting real annoying real fast.
Right now my workaround is to leave web.config read-only - so Visual Studio cannot add assemblies to it.
Update
Screenshots as proof:
Project Property Pages before:
Web.Config before:
Project Property Pages after:
Web.config after:
Update Two
It should be pointed out explicitly that the web-site works without these extraneous references being added. My interim solution is to keep web.config read-only, and hit Cancel whenever Visual Studio complains that it's read-only as it tries to modify it. If i can just stop Visual Studio from trying to modify it in the first place...
Update Three
It looks like it's not possible. Someone can feel free to give the correct answer, "You cannot stop Visual Studio from adding assemblies to your web.config." and i'll mark it.
The only reason i'm keeping the question up is that hopefully someone knows the super-secret option, or registry key, or project or solution setting, to tell Visual Studio to stop thinking.
Update Four
i didn't accept the accepted answer, and i'd unaccept it if i could. i'm still hoping for the panacea. But right now i'm leaning towards:
Answer: cannot be done (manu08)
Workaround: filtered GAC assemblies registry key (Nebakanezer)
How do i stop Visual Studio from adding assemblies to my web.config?
References
ASP Net - Visual Studio keeps adding Oracle assemblies to web.config
Why are the Visual Studio Add-In Assemblies being added to my web.config?
Visual Studio Adds Assembly Reference To web.config
removing VsWebSite.Interop Assembly from Web.Config
Visual Studio 2005 automatically adding references to web.config on build
Maybe the "Avatar DotNet Library" is referencing those assemblies by itself.
The references of a referenced assembly are needed to correctly deploy a project.
Otherwise, how could the referenced assembly work?
Note that it's possible that your referenced assembly does not use its own references, although they exists.
Edit: You can use the great tool ".Net Reflector" to check this.
I used VS2005 to edit a .net 1.1 (VS2003) .aspx and saved it, then the web.config will mysteriously have the net. 2.0 assemblies added:
If I used VS2008 or VS2010, this does not happen. So I believe this is is a bug in the VS2005 IDE.
I had this problem with Visual Studio 2005 (but I'm happy to report that the solution works for VS 2008, see bolded text below). There is a registry section that VS checks before it adds assemblies to the web.config file.
Here is the key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Projects\{E24C65DC-7377-472B-9ABA-BC803B73C61A}\FilteredGACReferences
So, let's say you don't want Visual Studio to add the Microsoft.VisualStudio.Designer.Interfaces assembly to your web.config. Add the following entry to your registry and you are set.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Projects\{E24C65DC-7377-472B-9ABA-BC803B73C61A}\FilteredGACReferences\Microsoft.VisualStudio.Designer.Interfaces
It worked perfectly for me. And yes, the rest of your team will have to do the same, but at least you don't have to manually remove the entries every time :)
To make it work for VS 2008 - just change the 8.0 in the registry path to 9.0
Convert you "Web Site" project to a "Web Application" project.
A "Web Site" does not have a project file, so it contains all assembly references in the web.config. A "Web Project" has a project file, and all references are stored in the project file.
Remove the References.
If it is a web app: you can see the References under Solution Explorer.
If it's a website: right-click the project on Solution Explorer then select Property Pages. Manage them there.
HTH
If a shared assembly references them, then they will be added to the calling project as well.
Since the Avatar library makes these other references, Visual Studio adds these references to the main project as well. Otherwise, a call into the Avatar library could fail since the reference it needs is missing.
Well this might seem like a hack but given your requirements another option would be to load the Avatar assembly dynamically using Assembly.Load or LoadFrom at runtime. This would keep a reference out of the main project and should then prevent the extra reference lines in the web.config. This would only really be practical though if you were only using a small number of classes from the Avatar project. I would make a third project that both projects referenced that held interfaces that one or more Avatar classes implemented in order for the main project to maintain strict typing when handling Avatar instances. I admit this could be a lot more work that previously submitted answers. If your interested in this method search google for creating plugins in .Net
As long as you are using a website, rather than a webapp, I don't know of any way to stop Visual Studio from adding assemblies to your web.config. This same problem of sorts happens for my company's solutions as well.
You cannot stop Visual Studio from adding assemblies to your web.config.
Sorry, you cannot stop Visual Studio from adding assemblies to your web.config, but all is not lost.
I have hit this in the past; someone had added some references (including WinForms) to a low level data access assembly. The web-site used the low level data access assembly and therefore had WinForms etc added to the web.config file.
The solution was to move his code into the correct assembly and remove the incorrect reference.
If you can not sort how the assembly that has the unwanted references and you know you are not calling code that depends on the unwanted references. Then you can (none of these are nice)
Write a custom install action that automates the removal of these unwanted assembly references from the web.config
Write a custom MSBUILD action to remove then at the time of the build
Use a different hand-written web.config file when the application is installed.
It can take ages to find how why Visual Studio is adding a reference to the web.config file. You have to hand-check EVERY assembly that is used directly or indirection by the web site.
I know and appreciate why Microsoft invented Web Sites in ASP.NET 2.0, but sometimes they just plain suck. If it is practical for you, convert your site to a Web Application Project, and problems like this will go away.
If that is not practical for you, try to re-factor as much code as possible into a separate class library project. Any references you can move out of the web site and into the class library will cut down on web.config changes.
EDIT: To clarify, in a Web Site, the aspnet compiler compiles everything (markup, code-behind, the lot), so all assembly references must go into web.config. However, in a Web Application Project, the C# or VB compiler compiles the code-behind files into a separate DLL, which is then referenced by the aspnet compiler when it compiles the markup. In this scenario, assemblies that are only referenced in code-behind files will go into the code-behind DLL and not touch web.config at all. Only assemblies that are directly referenced in markup will go into web.config.
I don't believe you can prevent Visual Studio from automatically adding references to assemblies that are referenced by others.
One solution is to create a Web Setup project with a custom action that automates
the removal of these unwanted assembly references from the web.config.
Those are all the assemblies required by your project, in some shape or manor and the aid the compilation that ASP.NET does on your pages at runtime. They are probably being imported in by either by code you are using in your project or another library that is using them.
But according to the documentation. These are the assemblies defined in your global web.config which can be found in C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG:
<assemblies>
<add assembly="mscorlib" />
<add assembly="System, ..." />
<add assembly="System.Configuration, ..." />
<add assembly="System.Web, ..." />
<add assembly="System.Data, ..." />
<add assembly="System.Web.Services, ..." />
<add assembly="System.Xml, ..." />
<add assembly="System.Drawing, ..." />
<add assembly="System.EnterpriseServices, ..." />
<add assembly="System.Web.Mobile, ..." />
<add assembly="*" />
</assemblies>
If you look there is an assembly="*" reference being added. And if you read the documentation about this command it says:
Optionally, you can specify the
asterisk (*) wildcard character to add
every assembly within the private
assembly cache for the application,
which is located either in the \bin
subdirectory of an application or in
the.NET Framework installation
directory
(%systemroot%\Microsoft.NET\Framework\version).
This means that any assembly in your /bin directory or in the .NET Framework installation directory is going to be included already.
What this tells me about your problem is that those assemblies that are being included are already referenced in some way to your project. And they are probably coming from the Avatar Dot Net Library or some controls on your page. Check the "References" folder in your Visual Studio project on the Avatar Library for these references you don't want. Because that is where the build process gets these libraries from.
So in other words if you don't want them to be included scrub your referenced projects of all references of these libraries.
Alternatively you can use a MSBuild XML parser to drop that section of the web.config each time you run your build process. Personally I use a task called XmlUpdate to modify certain parts of my web.config to get it production ready. If you would like to do the same it is part of the MSBuild Community Tasks.
If you are running on a vista or server 08 machine, you can use the appcmd command line utility to remove it after rebuilding rather than manually removing it.
http://technet.microsoft.com/en-us/library/cc772200(WS.10).aspx
http://learn.iis.net/page.aspx/114/getting-started-with-appcmdexe/
see http://msdn.microsoft.com/en-us/library/ms178728.aspx
there it's explained that what you see in Property Page is not all, implicit references exist also in Machine.config file and are added at compile time. Hope this helps.
I would start by checking the "using" statments in your code files as well as any references in your .aspx, .ascx files. It sounds like you've referenced some of these (I know some are added by default from the Add New Item templates.