Visual Studio Error: The "GenerateResource" task failed unexpectedly - visual-studio

When building a VS 2008 solution with 19 projects I sometimes get:
The "GenerateResource" task failed unexpectedly.
System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
at System.IO.MemoryStream.set_Capacity(Int32 value)
at System.IO.MemoryStream.EnsureCapacity(Int32 value)
at System.IO.MemoryStream.WriteByte(Byte value)
at System.IO.BinaryWriter.Write(Byte value)
at System.Resources.ResourceWriter.Write7BitEncodedInt(BinaryWriter store, Int32 value)
at System.Resources.ResourceWriter.Generate()
at System.Resources.ResourceWriter.Dispose(Boolean disposing)
at System.Resources.ResourceWriter.Close()
at Microsoft.Build.Tasks.ProcessResourceFiles.WriteResources(IResourceWriter writer)
at Microsoft.Build.Tasks.ProcessResourceFiles.WriteResources(String filename)
at Microsoft.Build.Tasks.ProcessResourceFiles.ProcessFile(String inFile, String outFile)
at Microsoft.Build.Tasks.ProcessResourceFiles.Run(TaskLoggingHelper log, ITaskItem[] assemblyFilesList, ArrayList inputs, ArrayList outputs, Boolean sourcePath, String language, String namespacename, String resourcesNamespace, String filename, String classname, Boolean publicClass)
at Microsoft.Build.Tasks.GenerateResource.Execute()
at Microsoft.Build.BuildEngine.TaskEngine.ExecuteInstantiatedTask(EngineProxy engineProxy, ItemBucket bucket, TaskExecutionMode howToExecuteTask, ITask task, Boolean& taskResult) C:\Windows\Microsoft.NET\Framework\v3.5
Usually happens after VS has been running for about 4 hours; the only way to get VS to compile properly is to close out VS, and start it again.
I'm on a machine with 3GB Ram. TaskManager shows the devenv.exe working set to be 578060K, and the entire memory allocation for the machine is 1.78GB. It should have more than enough ram to generate the resources.

From https://social.msdn.microsoft.com/Forums/vstudio/en-US/5154ef26-ccfe-44d5-a322-6804b61ac774/systemoutofmemoryexception?forum=clr:
Try deleting the .suo file and re-opening the solution.

Sounds like a bug.
http://www.codeprof.com/dev-archive/66/6-27-664019.shtm
Toward the bottom, someone suggests adding:
<GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>
to your project file. Seems kind of dubious, but worth a shot.

In case someone else is looking in the future...
In my case, turned out I had a corrupted resx file.
I had increased my GDI handles and the compile error went away.
But then when I tried to run the app (with the debugger),
We have a login screen that loads the main screen. The login screen called the main screen's "show" event... and the main object never got instantiated - with no error's being raised.
I reverted the resx file to a previous one and everything is fine now.
Visual Studio 2008, VB.Net, Windows 7

Can you please try adding this property under the first PropertyGroup in your project file?
<GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>
Let me know if that works.

I used to hit this now and again with larger solutions. My tactic was to break the larger solution down into smaller solutions.
You could also try:
http://stevenharman.net/blog/archive/2008/04/29/hacking-visual-studio-to-use-more-than-2gigabytes-of-memory.aspx

I have already passed by this erros sometimes. All you must do is delete all files in the obj path. After that clean and rebuild your solution and it´s done.

"Clean solution" works fine. Top Menu Build ->Clean , then build, debug and
publish all work fine again. Also antivirus like AVAST best disabled to publish and install trouble free. Re-enable after.

TFS likes to mark files as Read Only.
delete the contents of obj/x86

Related

Clickonce deployment results in "null reference" error in InitializeComponent();

Clickonce deployment of a Winforms application results in "null reference" error in InitializeComponent(); Running the executable directly does not produce the error.
Any ideas as to why that might happen?
edit:
Seems to be related to getting the value of Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
This is not a ClickOnce problem per se, it's a problem with your application. If you track down the exe file under \apps\2.0\obfuscatedfoldername\obfuscatedfoldername\xxxx...tion... (where xxxx is the 1st four characters or your assembly name) and double-click on it, does the application run? Probably not.
Put some try/catch statements in with a messagebox showing the exception if it has one, to try to figure out exactly what line of code is causing your problem. It doesn't make sense that it would be Environment.GetFolderPath, unless you're doing something weird with it, so find the exact line causing the problem and post it back here.

TFS API DownloadFile( ) functions cause exception when debugging

Whenever I call Item.DownloadFile(string localFileName) or VersionControlServer.DownloadFile(string serverPath, string localFileName) I get a FileNotFoundException whenever I try to debug in Visual Studio: Could not find file 'C:[Project Path]\bin\Debug\[ProjectName].vshost.exe.config'.
When I build the application and run it outside of visual studio there is no problem calling these functions. It works perfectly fine. Anyone know what could be causing it?
Before you ask, no, that file does not exist. I'm not doing anything with a config file, I don't need or want it to exist. I don't understand why it is even trying to access that file when I debug. When I run the application outside of visual studio that .config file still does not exist but I get no exception because it's not trying to access that file.
Also, it is not a vshost problem either. When I uncheck "Enable the Visual Studio hosting process" I get the same exception except when debugging but the file name changes from "[ProjectName].vshost.exe.config" to "[ProjectName].config"
Currently, when I want to debug this project I have to put a MessageBox.Show( ) function right after every call to DownloadFile( ) and run my application outside of visual studio. When that MessageBox is displayed then I can use attach to process and put a break point on the next line after that MessageBox, click OK on the messagebox and then it will catch the break point. But when I'm downloading files in a loop and want to debug the loop it's extremely annoying and time consuming to attach to process after DownloadFile is called, stop debugging before the next DownloadFile is called, attach to process again after DownloadFile is called, and keep repeating that all day long.
I'm not totally sure, but looks like it has something to do with the current path and the Workspace where you download the file to.
If you don't explicitly specify the workspace, the TFS API will try to determine it from the current path of your application by looking if that path is declared in a Workspace as a Mapping.
If I remember correctly, you can download an item from a Workspace object (or specify the Workspace in the operation), try to modify your code to do that and see if it's better.
You can also try to change the current path of your debugging session to something "inside a Workspace"

Visual Studio 2010 "Not enough storage is available to process this command"

I'm fighting with VS 2010 and this error that seems to be very common in previous versions, but it looks like not everyone is having it in the latest version.
I've got VS 2010 SP1 and I'm getting this error quite often.
The problem is that it's not even enough to restart VS in order to make it go away, I usually have to restart my PC, and I'm losing a lot of time doing this (it's quite frequent)
I've got Windows 7 32bits (can't upgrade to 64 bits, the company doesn't allow it), and I can't do things like creating another solution (please don't reply this :) )
I've used the command to make devenv.exe LARGEADDRESSAWARE, but the error keeps on happening.
My virtual memory size is set to automatic, and the weird thing is that VS doesn't even take 2GB of ram, so I don't know if the error is really because it's lacking memory, or if it's some bug in the program
Any ideas, things to try, something?
I tried everything else as well. The problems continued to come back until I tried
http://blog.rongabriel.com/2010/03/08/not-enough-storage-is-available-to-process-this-command/
Edit: Link is dead, archived version: http://web.archive.org/web/20100929160038/http://blog.rongabriel.com/2010/03/08/not-enough-storage-is-available-to-process-this-command/
Click on Start > Run > regedit & press Enter
Find this key name HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters
Locate IRPStackSize
If this value does not exist Righ Click on Parameters key and Click on New > Dword Value and type in IRPStackSize under the name.
The name of the value must be exactly (combination of uppercase and lowercase letters) the same as what I have above.
Right Click on the IRPStackSize and click on Modify
Select Decimal enter a value higher than 15(Maximum Value is 50 decimal) and Click Ok
You can close the registry editor and restart your computer.
This can be found under MS KB https://support.microsoft.com/en-us/kb/285089
Have a look at
Visual Studio 2010 -- how to reduce its memory footprint
I think I got the best results when I turned off C++ headers index. YMMV
Check the output project type in properties. In my case it was changed to "Windows Application" though it was a "Console Application".
Switching back to console application solved my problem.

Error HRESULT E_FAIL has been returned from a call to a COM component

In Silverlight 4 app; what does this error mean?:
"Error HRESULT E_FAIL has been returned from a call to a COM component."
It's a very generic error. The VS debugger doesn't point to the exact location of the error when debugging.
This is kind of an old question, but I figured I'd give my answer since I found this thread by Googling for the exact same problem.
In my case, I'd copied some sample XAML from the web to get started with Silverlight Toolkit 4. That sample XAML contained a simple button with a click event handler that didn't relate to any handler that actually existed in my code behind. I didn't notice this simple problem at first, because the compiler didn't give me an error message, I just saw the "Error HRESULT E_FAIL has been returned from a call to a COM component" message above at runtime. It was only when I isolated my sample XAML by copying it into a brand new Silverlight application without any other content that the real underlying problem was revealed at compile-time.
So, if you've got the same error message at runtime, my advice is to check your XAML carefully for any errors that you had expected should have been picked up at compile time, but which for some reason ended up as the runtime error noted above. In order to debug, you can do what I did and isolate the code that's causing the error in a standalone Silverlight app with no other content, and see if like me you get a more helpful error message to guide you.
HTH.
There are many solutions out there but this is the only solution that worked several times for me.It has been tried on VS2012 VS2013 and VS2015, I find it working equally good for all.Just follow steps bellow to fix this issue
Step 1 : Close Visual Studio
Step 2 : Delete *.csproj.user and *.suo files
Step 3 : Reopen VS, and try to run project again in debug mode.
NOTE : This situation occurs when multiple users working on same
project with different VS versions .suo file is not supported
for round-tripping between the two VS versions.It contains information
about what settings current user has selected for his/hers VS working
environment.
In my situation:
I create a
class MyControl : ContentControl {
}
By default, the class is not public and XAML cannot load it and throw exception
Error HRESULT E_FAIL has been returned from a call to a COM component
Just change the scope of class to public and error disappear.
Hope this help.
PS. Microsoft should provide more on information than just throw a mystery error message without any stack trace.
I also had this error and I found that this problem is related to not have added all requiered assemblies to your project. In my case I was using a UserControl with a depency with the Silverlight Toolkit and I havent added this reference.
I just added the reference and everything solved :)
I had this error using the current SL4 Telerik controls. A similar issue has been reported here with a solution ... of sorts. The problem seems to be with the way Expression Blend manages the cache of controls.
Here's one way to generate this error, which I stumbled upon today. We have the following button in XAML:
<Button x:Name="button" Click="Button_Click" Content="Click me" />
The event handler that handles the button's Click event is as follows:
private void Button_Click(object sender, RoutedEventArgs e)
{
button.Margin = new Thickness(0, double.NaN, 0, 0);
}
When I click on the button I get the aforementioned error. The same error arises if I replace NaN with PositiveInfinity or NegativeInfinity.
Interestingly, I get a different error message if the first parameter of the Thickness constructor contains the NaN instead of the second.
I had this error from problems with XAML. The strange thing was that I had missing resources used by Style and Margin attributes - which means the app runs fine, and even resharper only reports a 'hint'.
Once I cleared up those problems my "Error HRESULT E_FAIL has been returned from a call to a COM component." disappeared. As others have said though, this is a vague error, very difficult to debug. In this case I have inherited a large project with 100's of VS and ReSharper messages with varying severity - missing StaticResource on Style attributes were not the first place I checked!
I had this error in my xaml page and there were no syntax errors. Cleaning and re-building the project solved my issue. fyi...
The IIS App Pool has to run as an account that has query access to the Team Foundation Server. This fixes the problem for me.
Most of the reason of this problem related dependency propertied on component design.
You just face off this problem on design.
Soulution is easy but takes time :) Clean project and rebuild all. When you enter the desing again you should see everything is fine!
I hope this helps!
If you see this exception recently, please try to re-install silverlight sdk4.
This is a security and permissions issue. Look into the IIS and make sure Integrated Security is ON. Then set Application Protection level to Medium (If it is high then this might be the result). Then check your Web.Config file. Make sure impersonation is off.
This should help.
I had this problem while I was encoding Live video and audio (using Microsoft Expression) and the next piece of code throws the exception randomly:
// Set bitrate
liveJob.OutputFormat.VideoProfile.Bitrate = new ConstantBitrate(2500);
// Set Video size
liveJob.OutputFormat.VideoProfile.Size = new Size(320,240);
until i've figured out that the second line throws the exception while the first one is still running in another thread !
and of course, it was my fault - i've called the method in code, and it was also been called by Click event...
I had this exception and went nuts. I would advice you check if you had recently installed a component that had possible conflicting namespace items. In my case I installed the windows phone tool-kit which had items that were similarly named with the stock tool kit on windows phone.
Asap I uninstalled this from the Nuget package manager, all was back to normal.
Here is what FINALLY fixed this problem for us when trying to use MICROSOFT.TEAMFOUNDATION library when querying Team Foundation Server:
Team Foundation Explorer has to be installed with the currect version that is referenced in the application.
MSDTC – Configuration. (See DTC config below)
IIS App Pool has to run as an account that has query access to the Team Foundation Server
IIS App Pool has to run as an account that has COM access on IIS Server (We have a dedicated server for this so we made the identity user an administer on the local server).
Firewall has to be off or configured to allow COM access for DTC service.
DTC config ----
Click Start, click Run, type dcomcnfg and then click OK to open Component Services.
In the console tree, click to expand Component Services, click to expand Computers, click to expand My Computer, and click to expand Distributed Transaction Coordinator.
Right click Local DTC, and click Properties to display the Local DTC Properties dialog box.
Click the Security tab.
In the Security Settings section, click Network DTC Access.
In the Client and Administration section, select Allow Remote Clients and Allow Remote Administration.
In the Transaction Manager Communication section, select Allow Inbound and Allow Outbound.
In the Transaction Manager Communication section, select Mutual Authentication Required (if all remote machines are running Windows Server 2003 SP1 or Windows XP SP2 or higher), select Incoming Caller Authentication Required (if running MSDTC in a cluster), or select No Authentication Required if some of the remote machines are pre-Windows Server 2003 SP1 or pre-Windows XP SP2. No Authentication Required is the recommended selection.
I hope this helps.
My problem was a missing Style. I had overridden a control template with a custom brush like so:
<Style x:Key="MyCustomStyle" TargetType="Thumb">
<Setter Property="Template">
<Setter.Value>
<ControlTemplate TargetType="Thumb">
....
<TextBlock Foreground="{StaticResource MyCustomBrush}"
and was missing my definition of MyCustomBrush, like so:
<SolidColorBrush x:Key="MyCustomBrush" Color="#FFAC0909"/>
and then BOOM, app didn't startup and I got that COM error message.
Well, I was almost going to eat my computer..
At last, I find out the problem is that I MAYBE BY ACCIDENT removed one parameter of one Margin setting of an Image object in the XAML page, orz..
Margin="0,-20,0"
which should be
Margin="0,-20,0,0"
Obviously I didn't realized I have ever modified anything of the XAML, so I have been troubleshooting the code behind for "a little while"..
Fortunately, I found this post and rechecked everything include the XAML page.. that was ... something...
For me, I narrowed it down to a SplitButton control that I downloaded off CodePlex ages ago. I had upgraded the solution from Silverlight 4 to Silverlight 5 and got slammed with this error. I was able to narrow it down by commenting out the XAML to all controls then uncommented it back in one by one until the error appreared again:
System.Reflection.TargetInvocationException was unhandled by user code
Message=Exception has been thrown by the target of an invocation.
StackTrace:
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Delegate.DynamicInvokeImpl(Object[] args)
at System.Delegate.DynamicInvoke(Object[] args)
at Homexaml_3.BindingOperation(Object BindingState, Int32 , Action )
InnerException:
Message=Error HRESULT E_FAIL has been returned from a call to a COM component.
StackTrace:
at MS.Internal.XcpImports.CheckHResult(UInt32 hr)
at MS.Internal.XcpImports.UIElement_Measure(UIElement element, Size availableSize)
at System.Windows.UIElement.Measure(Size availableSize)
What fixed it was manually removing the outdated references System.Windows.Control and System.Windows.Controls.Toolkit then re-added them from the Silverlight 5 SDK folder.
Hope it helps someone (and helps me!) if it happens again a few months down the road.
I received this error recently in VS 2013 for a Silverlight 5 project. None of the above worked for me. Oddly enough, it was a threading problem (normally I am used to an exception that explains this if I am trying to create UIElements on a background thread by mistake).
Wrapping my code that adds UIElements to the MainPage with Dispatcher.BeginInvoke solved the problem:
Dispatcher.BeginInvoke(() =>
{
// your code
});
Most of the times its difficult to see where exactly the problem is located especially in XAML.
Another way to find out where its failing is to perform the following steps
Copy the exception it shows in the output window of Visual Studio. example. System.Reflection.TargetInvocationException
Click on Debug -> Exceptions. It shows up the exception list.
Click on the "Add.." button.
Paste the exception copied in the step 1 in the text box. Select "Common Language Runtime exceptions" in the drop down list.
Click on "Ok" button. The selected exception will be highlighted. Make sure you check the checkbox against the exception. Click on "Ok" button again to close the dialog.
Now run the application in debug mode. The application breaks when the exception occurs. Sometimes in the assembler mode as well.
At this point in time you have two options,
Click on the View details of the exception screen shown. Dig into
the inner exceptions until you get a clue from where its
originating.
View the call stack to see which code of line of your is causing
this exception. This will provide clues to resolve the issue.
For me, this was a XAML parsing error. In a data template, I had an extra S between two tags (probably because I pressed S instead of CTRL+S). For example...
<DataTemplate>
<Border/>s
</DataTemplate>
So, I would suggest you look for poorly formatted XML in the view that causes this exception when displayed.
In my case it was, when I tried to import database into the SSDT project, but this database already was in project, but was empty. I've just updated my project with Tools -> SQL server -> New schema comparsion. Source - database, target - project. Compare - update.
Hope it helps to someone
This error seems to be a 'catch-all' for errors that otherwise are not given a specific definition or tracing, especially those having to do with relatively external Xaml code.
In my particular case, there seemed to be an issue with the namespaces. My UserControl is in its own namespace (creatively named "UserControls"). My Pages are in their own namespace ("Pages"). I wanted to reference an enum definition in the Pages namespace from within my UserControl, so I simply added a using statement: using MySolution.Pages;. Trivial enough, and I didn't want to believe that this was the problem. But when I removed that using statement and simply created the enum in my UserControls namespace, voila, no more HRESULT error and also, as an added bonus, my dependency properties defined in the UserControl, which otherwise were mysteriously not showing up in the Xaml intellisense, suddenly were there and ready to use.
I suspect that underlying cause for this in my case was some sort of circular reference issue. And since there was no more specific error available to relate that information to me, it simply got shuffled into this HRESULT E_FAIL Com error.
I fixed this error by deleting the XAML file and add a new one from add new item. Then I pasted the XAML codes that was there in the old file.
This is an old question but in my case, none of the above solutions worked. I was trying to update the NuGet packages in Visual Studio 2017 but I was getting the following Exception.
update-package : Failed to add reference to 'System.Web.Razor'.
Error HRESULT E_FAIL has been returned from a call to a COM component.
In fact, other NuGet commands like restore-package were failing with similar exception message.
I discovered a few assemblies were missing under the packages directory so I deleted the packages directory and returned back to the Visual Studio 2017. When I opened the solution it asked me to restore the packages and after that, I was able to update the packages.
NOTE: Take a backup of package directory before deleting it.
I encountered this same error after installing VS2019 and trying to open a large solution (20+ projects), with both vcxproj and csproj projects, that target VS2015. The csproj all loaded fine, while the vcxproj all failed with the OP's error. Deleting the .vs folder did not work.
What did work was setting VC++'s "Fallback Location", under the "Browsing Database Fallback" settings.
Tools (menu)
-Options...
--Text Editor
---C/C++
---Advanced
----Browsing Database Fallback
-----Fallback Location
I set mine to D:\VC++\v16. Where I use v140 for VS2015 and v141 for VS2017. Also set "Always Use" and "Do not warn".
If anyone facing this issue, while adding reference in console/windows applications, follow the below steps
Open "Developer Command Prompt for VS 2017" as Admin
CD into "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\PublicAssemblies"
Run "gacutil -i Microsoft.VisualStudio.Shell.Interop.11.0.dll"
Restart Visualstudio
Reference - https://developercommunity.visualstudio.com/t/add-a-reference-raise-error-error-hresult-e-fail-h/260196

Visual Studio debugger problem

In Visual Studio 2008, after debugging about 1-2 minutes, when I press F10 (Step Over), the debugger hangs and Visual Studio freezes for 5-10 seconds and then go to the next line. Then whatever I do (F10, F5, F11, etc), the debugger continues the execution as if i pressed F5 and all my forms that I was debugging close. I always have to restart the application.
It is very hard to reproduce and it does not occurs every time I want to debug something. Does anyone has a solution ?
EDIT : I've managed to reproduce my problem with the following code :
static void Main(string[] args)
{
XElement e = new XElement("root");
Test(e, 0);
}
static void Test(XElement parentElement, int i)
{
if (i < 1000)
{
XElement element = new XElement("element");
parentElement.Add(element);
Test(element, ++i);
}
}
You need to put a conditional breakpoint on the line "XElement element = new XElement("element");" with the condition "i == 999". Then start the program, wait 2-3 seconds and put normal breakpoint on the line "parentElement.Add(element);". Now VisualStudio freezes and it is impossible to debug. In a WinForm application, it closes all the forms that are open after pressing F10.
But I found that if I disable the debug option "Call string conversion function on objects in variables windows" in "Tools -> Options -> Debugging", I can debug. It is slow but at least VisualStudio doesn't freeze. Does anyone know why it is doing this? Because I don't want to disable this option, it's really annoying to debug without it.
I also noticed that if I only put a breakpoint at the end of the main method, the code runs really fast compare to having a conditional breakpoint in the recursive method.
Try deleting the solution user options file (.suo) where the debug/breakpoint information is stored. You will lose all solution user settings, such as breakpoint locations. When you have "funny" debugging incidents, this is the first thing to try because this file can get corrupted.
If this does not solve the problem, then you have something else going on, such as threading issues, excessive memory fragmentation, garbage collection issues, dispose/finalize issues, and so on.
I found the answer to this question on another Stackoverflow thread. There's a MS hotfix for this issue.
I've found that I get slowdowns like this whenever I have added remote unc shares that don't exist to the list of symbol directories.
Try going to Tools -> Options -> Debugging -> Symbols and make sure that all of the directories in that list actually exist.
I have no idea how that would cause your program to continue after that point however.
Not sure I've ever run into this, but if I were you, if you haven't, delete your bin folder, and rebuild your project. Then run a clean solution to be safe. Sometimes, funky things can happen with your PDB's getting out of date -- so you need to clear them out.
Also, if your calling outside assemblies, remove them and reattach them to make sure you have the most up-to-date assemblies.
I have had this exact same problem just as you described. The MS Hotfix addressed the issue and now I install this hotfix whenever I do a fresh 2008 VS install.
Please download the fix from this link
http://support2.microsoft.com/hotfix/KBHotfix.aspx?kbnum=957912
I know this is an old thread but this occurred when debugging an Excel add-in in my case.
Problem was that my breakpoint was in a background thread and in my watch window I had an old check on the ActiveWorkbook in Excel. That call just like many others should only occur on Excel's main thread.
Once I removed that watch, it debugged just fine again.

Resources