Sometimes, not all the time, Visual Studio 2013 w/ Update 1 on an up to date Win7 x64 machine throws an exception when closing a file, or multiple files doing "Close All But This". A dialog is shown referring you to the "ActivityLog.xml" file at "C:\Users\\AppData\Roaming\Microsoft\VisualStudio\12.0" which has one of the following entries for each file that was being closed. I am using the latest version of DevExpress controls.
How can I fix this? I did not find any similar issues though post Is there something I can/should do about this VS 2013 exception? was vaguely similar but this does not happen when I open a solution.
So far, it seems to occur mostly when having multiple instances of VS2013 open but I am unable to repro at will. Clearing the ComponentModelCache did not help in that it has occurred again after clearing the cache. The solution was originally a VS2012 solution and all new DevX, MVC and EF components have been updated to latest versions with NuGet.
<entry>
<record>858</record>
<time>2014/02/17 20:22:45.177</time>
<type>Error</type>
<source>Editor or Editor Extension</source>
<description>System.ArgumentException: The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode)
at Microsoft.VisualStudio.NativeMethods.ThrowOnFailure(Int32 hr, Int32[] expectedHRFailure)
at Microsoft.VisualStudio.Shell.RunningDocumentTable.FindDocument(String moniker, IVsHierarchy& hierarchy, UInt32& itemid, UInt32& docCookie)
at Microsoft.VisualStudio.CodeSense.Editor.Roslyn.CodeElementTaggerProvider.CreateTagger(ITextView textView)
at Microsoft.VisualStudio.CodeSense.Editor.TaggerProvider`1.CreateTagger[T](ITextView textView, ITextBuffer buffer)
at Microsoft.VisualStudio.Text.Tagging.Implementation.TagAggregator`1.GatherTaggers(ITextBuffer textBuffer)</description>
This appears to be a bug in the Code Sense engine. They are requesting a document from the Running Document Table after the document has been closed. I encourage you to please file a bug on this (customer bugs get more attention than if I just filed it)
http://connect.microsoft.com/VisualStudio
The only thing you can do to stop this is to disable Code Sense
Tools -> Options
Text Editor -> All Languages -> Code Lens
Uncheck "Enable CodeLens"
Related
When I load up my VS2013 projects in 2015, all my razor views are filled with red squiggly underlines.
#model, #Scripts #url, #Html.Partial, lambda expressions
Intellisense is now fairly useless as it seems to be missing half the options.
Solutions I've seen involved deleting .vs folder, and devenv.exe /ResetUserData, however these don't work for me.
I'm on a fresh install of VS 2015 Community using the same install files as my colleagues. None of them have the razor issues, and they're working on the same projects as I am.
Any idea how to fix this?
Edit...Further Info!
I uninstalled/reinstalled VS 2015 Community, opened my projects, and the razor worked!
I then clicked on a notification saying to update NuGet. NuGet update installed, VS restarted, razor stopped working again. So the NuGet update is breaking razor??
Every time I open a razor file it says "An exception has been encountered. This may be caused by an extension. You can get more information by examining the file 'C:\Users\Jonathan\AppData\Roaming\Microsoft\VisualStudio\14.0\ActivityLog.xml'.
"
In the activity log I get the following error
"System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: Item has already been added. Key in dictionary: 'RazorSupportedRuntimeVersion' Key being added: 'RazorSupportedRuntimeVersion' at System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add) at System.Collections.Hashtable.Add(Object key, Object value) at System.Collections.Specialized.HybridDictionary.Add(Object key, Object value) at Microsoft.VisualStudio.Utilities.PropertyCollection.AddProperty(Object key, Object property) at Microsoft.VisualStudio.Html.Package.Razor.RazorVersionDetector.Microsoft.Html.Editor.ContainedLanguage.Razor.Def.IRazorVersionDetector.GetVersion(ITextBuffer textBuffer) at Microsoft.Html.Editor.ContainedLanguage.Razor.RazorUtility.TryGetRazorVersion(ITextBuffer textBuffer, Version& razorVersion) at Microsoft.Html.Editor.ContainedLanguage.Razor.RazorErrorTagger..ctor(ITextBuffer textBuffer) --- End of inner exception stack trace --- at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark) at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) at System.Activator.CreateInstance(Type type, Object[] args) at Microsoft.Html.Editor.ContainedLanguage.Common.ContainedCodeErrorTaggerProvider`1.CreateTagger[T](ITextBuffer textBuffer) at Microsoft.VisualStudio.Text.Tagging.Implementation.TagAggregator`1.GatherTaggers(ITextBuffer textBuffer)"
How do I fix this?
You dont need to reset the entire configurations of your Visual Studio using the devenv.exe /ResetUserData to workaround this
Instead of it, try to just delete the contents of this directory with Visual Studio closed then reopen it:
%LocalAppData%\Microsoft\VisualStudio\14.0\ComponentModelCache
Here's what FINALLY worked for me:
Start -> Run -> (Or Windows Key + R)
Then type "devenv.exe /resetuserdata" (no quotes of course)
I did not have to delete the .vs file, as some others had experienced.
See also: Visual Studio 2015 Broken Razor Intellisense
I've upgraded to mvc5 and so forth to razer 3. It solved my issue.
I followed this instructions :
http://www.asp.net/mvc/overview/releases/how-to-upgrade-an-aspnet-mvc-4-and-web-api-project-to-aspnet-mvc-5-and-web-api-21
Had the same issue. ResetUserData didn't work, etc. What ResetUserData did do though was reset some of the dialogs that were suppressed. Ultimately a dialog popped up stating "The 'CompatiblityCheckerPackage' did not load correctly." It told me to go to my users folder (path below) and check out the ActivityLog.xml. Turns out WebEssentials 2015 did not install correctly and was failing to load. I installed WebEssentials again and the Intellisense errors went away.
Full Path for me:
C:\Users\xxx\AppData\Roaming\Microsoft\VisualStudio\14.0\ActivityLog.xml
Hope this helps.
This could fix similar problems (I got it from somewhere, unfortunately I cannot remember, on Github)
Close VS Studio
Run command prompt as Administrator
In command prompt:
> cd "%ProgramFiles(x86)%\Microsoft Visual Studio 14.0\Common7\IDE"
> devenv /updateconfiguration
> devenv /clearcache
I hope the above will be helpful to someone.
Deleting the entire Solution and re-downloading it from Source Control is the only thing that worked for me. You might need to open the solution in VS 2013 first before you can open it in 2015... a very buggy Visual Studio release Microsoft!
Edit:
Another thing that is strange, at least for me... deleting the red zigzag underlined text then retyping it fixed the problem! Possibly just a random thing that happened to me.
I had same issue and none of these answers worked. What I finally saw was, my Views web.config file was referencing MVC 4, and my main web.config was referencing MVC 5. So I could compile fine but intellisense wasn't working. MVC 4 isn't supported in VS2015. Why my web.config files were different I don't know. When I updated MVC in VS2012 months ago it must not have updated that config file.
You don't to update anything.
Just delete component cache from this folder
C:\users\xxx\AppData\Local\Microsoft\VisualStudio\14.0\ComponentModelCache
And ot will work fine .
Try it
None of these solutions fixed it for me. What worked was ensuring my webpages version was up to date. So
<add key="webpages:Version" value="3.0.0.0" />
in the web.config, instead of version 2.0.0.0
And then closing and reopening visual studio with the same solution.
I know that this topic is out of date, but I've just overcome the same problem and my resolution is not related to any one of the listed here.
The issue is that in my project properties the parameter "Output path" (Build->Output) was a folder different from just "bin\". After changing it to bin\, reopening the Studio and rebuilding my project, everything worked out!
Hopefully, it might help someone.
I am using VS 2015 professional. Faced the same issue, tried all mentioned above solutions and nothing worked. Neither "devenv.exe /ResetUserData" nor "deleting content of ComponentModelCache".
The only way I managed to solve the issue is by modifying the installation:
Go to Program and Features -> Find Microsoft Visual Studio ... 2015 -> Click Change -> Select Modify -> Check "Microsoft Web Developer Tools" -> Click Update
That worked for me.
i have read a lot of solutions, a i have lose much time, and when i was sure to not resolve the problem of visual studio 2015 intellisense, eureka, some one was giving the right solution:
lean & clear 2 lines of code those I run in cmd (like administrator):
C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE>devenv /updateco nfiguration
C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE>devenv /clearcac he
whe restart visual studio maybe it ask to reinstall one tools that was broked.
Well you do but still fron now your intellisense is going work agane.
good luck at all and much thanks at Nadir
Just do one thing and go to:
Tools > Extension & Update > Update Your Visual Studio Version
It take some time but after that working fine.
Just Put a Break point on the First line
of Page. and remove it after few seconds... it will definitely work...
I am trying to deploy and test a Universal Windows App to a Surface Pro 3 directly from Visual Studio 2013 (Update 4) and I am unable to launch the App (by hitting F5). I am running into the following error and not able to find a fix to it. There are a bunch of solutions of DEP0700 errors online, but none of them work for the specific sub-error message Cannot map the serial well-known device name to a device interface GUID (blah blah blah)
Here is the error that I am seeing
Error : DEP0700 : Registration of the app failed. c:\Builds\TestAppRT\AppX\AppxManifest.xml(38,6): error 0x80070002:
Cannot map the serial well-known device name to a device interface GUID for the 11156705-8b60-4c7f-a75f-f8c7516401fc_1.0.0.0_neutral__1g7p71hbj7m7y package.
Check that the device name is correct. (0x80073cf6)
Have you declared any serial communication in your AppxManifest file?
If your other apps work, your issue might be because opening/editing ApxManifest file in the designer. Try making a new solution, and edit the manifest through only through XML Editor, if required & do not open with the designer.
Reference for more information:
http://ms-iot.github.io/content/en-US/win10/samples/SerialSample.htm
"Visual Studio 2015 has a known bug in the Manifest Designer (the visual editor for appxmanifest files) that affects the serialcommunication capability. If
your appxmanifest adds the serialcommunication capability, modifying your appxmanifest with the designer will corrupt your appxmanifest (the Device xml child will be lost). You can workaround this problem by hand editting the appxmanifest by right-clicking your appxmanifest and selecting View Code from the context menu."
I have a data driven subscription that renders the report in PDF. SSRS 2012, Win 2008 R2 (on Hyper-V) is used.
I have looked in ExecutionLog3, the shared data sets all successfully refresh, the reports successfully render and are output to the correct folder.
I did read somewhere that when rendering the reports in IE that the user needed permissions to the Temporary Internet Files folder, however I don't know if this is valid for data driven subscriptions? I did add the execution account (a local user) to have read/write permissions on the ReportServer temp internet folder.
Apart from this I have no idea what to look for to troubleshoot this issue? Any suggestions will be welcomed.
EDIT - 2012-11-19
Have found the following unhandled exception error in the ReportServer log:
ERROR: Throwing Microsoft.ReportingServices.ReportProcessing.RenderingObjectModelException: , Microsoft.ReportingServices.ReportProcessing.RenderingObjectModelException: A generic error occurred in GDI+. ---> System.Runtime.InteropServices.ExternalException: A generic error occurred in GDI+.
at System.Drawing.Image.Save(Stream stream, ImageCodecInfo encoder, EncoderParameters encoderParams)
at Microsoft.Reporting.Chart.WebForms.Chart.Save(Stream imageStream, ChartImageFormat format)
at Microsoft.ReportingServices.OnDemandReportRendering.ChartMapper.GetImage(ImageType imageType)
--- End of inner exception stack trace ---;
It turns out that the GDI+ drivers needed updating on Windows 2008 R2 Server and is a known issue. If you want to know what version of GDI+ you have then do a file search for gdiplus.dll.
I posted the same question here and got a response saying to update the drivers via a hotfix, which can be found at this link, and it provides the version of the gdiplus.dll that will be installed with the hotfix, so you can compare if there is a version change necessary.
You need to request the hotfix, and an email will be sent to you giving you the download location.
This also solved the issue of images not rendering as well as charts
It's a follow-up from this.
Windows Phone 8 C# project (MyApp), migrated from WP7.1. I've added a native Windows Runtime component library (AppLib) to the solution, created a reference. There's a public sealed ref class (MyClass) in it. There's a reference to it in the C# code (in OnLoaded of the main XAML page). The whole thing builds - meaning the metadata of the component is being generated.
When I'm trying to run on the emulator, the project fails with the exception or type BadImageFormatException with the following message:
An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
The error typically pops up when you try to mix CPU types in .NET.
The active platform is "Mixed platforms". In the Configuration Manager, it's configured to build MyApp for "x86" and AppLib for "Win32". In a vanilla freshly generated project that runs fine, the config is identical.
Question - what's wrong with that configuration? What do I need to check?
EDIT: I've added a second, blank C++ library to the solution - TestLib. This one loads and works as expected.
EDIT2: excluded everything from build in AppLib - it works. Now I'll be adding lines one by one, see which one causes the issue...
Totally my fault. When I changed the namespace of AppLib (see the linked question), I've left one little declaration in the library in a MyApp namespace.
The error is still misleading. I'd delete the question, but since the error message is sure to send someone on a wild goose chase with build CPU type and whatnot, let it remain.
Shouldn't a Windows Phone library be built for ARM in most cases? Have you had a chance to watch the "Windows Phone 8: Using C++ in your Applications" session from last week's //Build/ conference? That might include some answers.
For some weeks now we have been fighting with an issue where at a small number of customers our Outlook addin gets unloaded and disabled for yet undetermined reasons. By "disabled" I mean that Outlook changes the following registry value from 3 to 2 which in effect means that the addin will not be loaded on next startup:
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook\Addins\[OurAddin.sProgID]\LoadBehavior
There is no error message and neither do any exceptions show up in the log files that our addin produces itself.
I have already found the following page which specifically deals with the LoadBehavior change issue: http://blogs.msdn.com/vsod/archive/2008/04/22/Troubleshooting-com-add-in-load-failures.aspx
However, none of the possible reasons proposed there appear to be applicable:
The addin is not merely listed in the Disabled Items list.
There are no unhandled exceptions neither in the IDTExtensibility2 methods nor anywhere else in the code. All code is wrapped in try/catch equivalents and all exception output is emitted only via OutputDebugString or into a log file.
The error appears to be independent of anti-virus software, i.e. it also occurs with it disabled.
Disabling all other addins also has no effect on the error.
So, what else can cause Outlook to disable an addin?
Some more details / observations:
We haven't been able to reproduce the issue in our test environments so far so we haven't yet been able to attach a debugger while the issue occurs.
The issue never occurs while we try to watch what happens via remote support (TeamViewer). I suspect this is because TeamViewer uses a hook DLL that injects itself into all running processes (including Outlook) and thus affects the memory layout, timing, thread order, whatever.
Whenever we compile a new version of the addin to try out something new the addin will typically work fine for a couple of hours or even days only to eventually get disabled again. Once this has happened all subsequent attempts to get the addin to load on that machine (by manually changing back the LoadBehavior value) will fail (i.e. LoadBehaviour will simply change back to 2) until we compile and deploy another build (or try to watch using TeamViewer - see above).
Typically the addin will get unloaded right on Outlook startup though occasionally it also does happen after Outlook has already been running for some time. The log file in those cases looks completely inconspicious - the addin simply goes through the regular shutdown steps just as if Outlook had been closed normally.
As far as I can tell from our log files and by observing the issue via SysInternals ProcessMonitor, when the addin get disabled on Outlook startup (rather than during the session) the DLL gets unloaded even before the COM object (i.e. the addin) gets instantiated (log messages in the constructor never show up).
We have put OutputDebugString messages in initialization sections (this a Delphi DLL). None of them show up when the addin fails to load.
Only a very small fraction of our customers is affected by this issue. We have several tens of thousands of installations from whom we haven't received any reports about this.
UPDATE: It seems that often (but not always) one of the last things that gets logged before the addin gets unloaded is an exception with text "OLE error 800A01A8". That exception gets caught by a global exception handler built into the framework I'm using (Add-in-Express) and does not appear originate from anywhere it my own code every single method of which is by now entirely wrapped in try..catch. This typically occurs right after I set the visibility of my CommandBarButtons from an Inspector's Activate event handler.
Common properties of all affected machines:
Windows XP Professional, up-to-date patch level
Outlook 2003 Professional, up-to-date patch level
varying versions of McAfee Virus Scan (though disabling it has no effect - see above)
Users are members of the local Administrators group
One more thing to note which very probably is significant as well (though maybe not as much as I first thought):
We are using a licensing / copy protection module from a third-party vendor which wraps the compiled DLL in a "shell" and only unpacks it on-the-fly. Ever since I found out that the addin gets unloaded even before any of our own code gets executed this has been my prime suspect. However, while the vendor confirmed that there may be unhandled exceptions in their code a log file produced by a special debug version of the protection shell showed that the unpacking process completed successfully and control was already handed back to the protected DLL before Outlook unloaded the addin. So it appears that whatever causes Outlook to unload our addin happens between the completion of the protection shell's initialization and our own code.
Any more ideas?
My company has been putting up with what sounds like the same issue you are seeing for years. The plug-in we have is a VB6 COM add-in for Outlook 2003 and it’s deployed on several hundred machines that get cycled hundreds (if not thousands) of times a day. We go through the load and unload cycles a lot.
We get a fair bit of the general errors where the plug-in is loaded but not connected and we handle that in code. (Obviously not production quality)
Dim outlook As outlook.Application
Set outlook = CreateObject("Outlook.Application")
outlook.COMAddIns("MyFancyDancyPlugin").Connect = True
Rarely, but not so rare that it isn’t an annoyance, we see the plug-in reach a state where it is loaded and we can see it in “Tools>Options>Others>Advanced Options> Com Add-Ins”, but we just can’t connect to the thing. If you try to connect you don’t get an error it just switches back to disconnected. [The equivalent of switching back to a 2 in the registry key] The COM object as far as I can tell is never created. The item is not listed in the Disabled items.
We don’t actually have to redeploy to correct this error. Removing the object through the Com Add-Ins dialogue and then re-adding it there seems to correct the issue. This is still not an acceptable solution but it does get things back and running without a reinstall.
Windows XP Professional, up-to-date
patch level
Outlook 2003
Professional, up-to-date patch level
varying versions of McAfee Virus Scan
(though disabling it has no effect -
see above)
Users are members of the
local Administrators group
This seems to fit, we don't use McAfee but the virus scanner also doesn't interact with outlook or the com add-ins. We also don't use a copy protection app.
I'm sorry I can't be of more help, but I would love to root cause this.
I am also working on Outlook Add-In and I know one reason when the Add-In gets disabled. some time when Outlook shuts down abruptly or user forcefully shut down the Outlook, add-In gets disabled. I am not sure if this is the reason in your case but it could also give you some direction to think of.
I some time use this method (closing the outlook using task manager while it is still loading) to simulate this behavior and actually I have developed a tool which scans all the machines provided to it and checks if the add-In is disabled on a machine and if yes it changes the registry value to enable it.
maybe you are a lockback policy victim. add a bypass key to registry, then it works.
modern office versions or vsto creates the key while installation. the effect is: install
a modern office too and the adddin now are also loaded in older office. please take a look
code snippet taken from NetOffice http://netoffice.codeplex.com
public static void RegisterFunction(Type type)
{
try
{
// add codebase value
Assembly thisAssembly = Assembly.GetAssembly(typeof(ExampleClassicAddin));
RegistryKey key = Registry.ClassesRoot.CreateSubKey("CLSID\\{" + type.GUID.ToString().ToUpper() + "}\\InprocServer32\\1.0.0.0");
key.SetValue("CodeBase", thisAssembly.CodeBase);
key.Close();
key = Registry.ClassesRoot.CreateSubKey("CLSID\\{" + type.GUID.ToString().ToUpper() + "}\\InprocServer32");
key.SetValue("CodeBase", thisAssembly.CodeBase);
key.Close();
// add bypass key
// http://support.microsoft.com/kb/948461
key = Registry.ClassesRoot.CreateSubKey("Interface\\{000C0601-0000-0000-C000-000000000046}");
string defaultValue = key.GetValue("") as string;
if (null == defaultValue)
key.SetValue("", "Office .NET Framework Lockback Bypass Key");
key.Close();
// add addin key
Registry.ClassesRoot.CreateSubKey(#"CLSID\{" + type.GUID.ToString().ToUpper() + #"}\Programmable");
Registry.CurrentUser.CreateSubKey(_addinRegistryKey + _prodId);
RegistryKey rk = Registry.CurrentUser.OpenSubKey(_addinRegistryKey + _prodId, true);
rk.SetValue("LoadBehavior", Convert.ToInt32(3));
rk.SetValue("FriendlyName", _addinName);
rk.SetValue("Description", "NetOffice COMAddinExample with classic UI");
rk.Close();
}
catch (Exception ex)
{
string details = string.Format("{1}{1}Details:{1}{1}{0}", ex.Message, Environment.NewLine);
MessageBox.Show("An error occured." + details, "Register " + _addinName, MessageBoxButtons.OK, MessageBoxIcon.Error);
}
}
If you have the ability for your users to run a debug program to get more information about the problem when it happens, try using Add-in Spy from Microsoft.
http://msdn.microsoft.com/en-us/library/cc984533(v=office.12).aspx
I was having an add-in fail to load and discovered that it was happening because a dependency wasn't getting preloaded. This tool should be able to tell you what specific error is happening when the Outlook add-in fails to load.
Just to close this up: The problem did eventually turn out to be caused by a bug in the third-party licensing wrapper we were using. It has been confirmed by the vendor and was fixed in more recent releases.