the original code is like this.
else
{
continue;
}
}
break;
}
case UserType.Individual:
{
You want to install SP1 for Visual Studio. See http://devnet.jetbrains.net/docs/DOC-1204
Related
I have recently installed VS 2019 and opened up my project I created in VS 2017. The software works fine but there is a bug in VS with lambda captured variables. MS apparently is aware of said issue, but I was wondering if anyone else had come across this recently and if you have, have you managed to solve it?
Example bit of code from my project, the intellisense has flagged up every line where "[this]" appears. The error / bug reads
lambda captured variable of type "MainPage^*" cannot be copied to closure class field of type "MainPage^"
if (_serialPort1 != nullptr)
{
concurrency::create_task(WriteToSerialDeviceAsync(cancellationTokenSource_serialPort1->get_token(),
Arduino_Device.Outgoing_Bytes, PORT_1)).then([this](concurrency::task<void> previousTask) {
try
{
previousTask.get();
}
catch (Platform::COMException^ ex)
{
this->DataStreamWindow->Text += "\r\n!EXCEPTION CAUGHT! " + ex->Message;
}
});
}
Ok, I managed to stumble upon a somewhat ugly hack to fix this.
Rather than pass [this] into the lambda, I added the line auto _this = this; prior to creating any tasks. This did however mean that any variables which were accessed using this->SomeVariable became _this->SomeVariable.
So my example above now looks like this.
if (_serialPort1 != nullptr)
{
auto _this = this;
concurrency::create_task(WriteToSerialDeviceAsync(cancellationTokenSource_serialPort1->get_token(),
Arduino_Device.Outgoing_Bytes, PORT_1)).then([_this](concurrency::task<void> previousTask) {
try
{
previousTask.get();
}
catch (Platform::COMException^ ex)
{
_this->DataStreamWindow->Text += "\r\n!EXCEPTION CAUGHT! " + ex->Message;
}
});
}
Hope this is of use.
If so then why copying outside the task? You could do
if (_serialPort1 != nullptr)
{ concurrency::create_task(WriteToSerialDeviceAsync(cancellationTokenSource_serialPort1->get_token(),
Arduino_Device.Outgoing_Bytes, PORT_1)).then([_this = this](concurrency::task<void> previousTask) {
try
{
previousTask.get();
}
catch (Platform::COMException^ ex)
{
_this->DataStreamWindow->Text += "\r\n!EXCEPTION CAUGHT! " + ex->Message;
}
});
}
But based on your problem this is not the proper solution. You better find what's wrong with your project migration to VS 2019.
In Visual Studio 2015 RC, there was that Feedback smiley in the upper right of the main window.
Unfortunately, it is still there in the final release of Visual Studio 2015:
I've searched all through the options and settings and found no way to hide this smiley.
My question:
Any option or other (Registry etc.) hack to remove the smiley?
Update 2015-12-01:
Yesterday Update 1 for Visual Studio was released.
While I still find no option to hide the smiley, they at least provided a less distracting icon for it:
Edit:
Visual Studio 2015 Update 1 changes the feedback icon to an understated black and white one so no more smiley! It's not mentioned in the release notes.
Original answer:
As in OPs answer, this icon is specified in this registry key:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0_Config\MainWindowFrameControls{F66FBC48-9AE4-41DC-B1AF-0D64F0F54A07}
if you delete the key, Visual Studio recreates it, but if you invalidate the "Package" value of the registry key and restart Visual Studio then the smiley icon is gone:
However, when you install a Visual Studio update (eg SSDT, Resharper) the installer restores the package value, and the smiley is back. So I have created a registry file like this to run when the smiley reappears:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0_Config\MainWindowFrameControls\{F66FBC48-9AE4-41DC-B1AF-0D64F0F54A07}]
#="Feedback Button"
"Package"="{00000000-AA51-43B1-97EE-509A33B681F3}"
"DisplayName"="#1001"
"ViewFactory"="{060EAB95-139E-407D-BEDC-CC2B7A9B39D4}"
"ViewId"=dword:00000064
"Alignment"="TitleBarRight"
"Sort"=dword:00000064
"FullScreenAlignment"="MenuBarRight"
"FullScreenSort"=dword:00000064
This doesn't seem to affect startup time or stability, but there are no guarantees, registry changes are bad mmm, etc.
Thanks to Jehof's hint for Visual Studio 2013, I was able to resolve this:
Deleting the following Registry key actually helped.
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0_Config\MainWindowFrameControls\{F66FBC48-9AE4-41DC-B1AF-0D64F0F54A07}
(Please note the 14.0 instead of the 12.0 in the linked blog post)
After restarting Visual Studio, the Feedback button is now gone.
Update one day later
Suddenly the Feedback icon is here again. And the registry key is here again, too.
How on earth can this happen?
Seems the smiley resurrected from its grave. I'm really frightened now…
Following the advice in this thread, I modified also the registry key and it worked at first, but VS2015 keeps recreating the key to its original value after a while.
To remedy that, I added a VS2015 shortcut in Taskbar, and then Shift+Right Click to access 'Properties'. Replace the Target path of the shortcut pointing to devenv.exe with a own local c:\tools\vs.bat file.
Additionally, I changed Run to 'Minimized' in the shortcut properties. The vs.bat looks as follows:
#echo off
reg ADD HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0_Config\MainWindowFrameControls\{F66FBC48-9AE4-41DC-B1AF-0D64F0F54A07} /v Package /t REG_SZ /d {00000000-AA51-43B1-97EE-509A33B681F3} /f 2> nul
start /B devenv.exe
This ensures the key is overwritten every time I start VS2015 via Taskbar shourtcut. I found this to be reliably working for me.
If you ever start VS without this (e.g., on a VS restart), you may need to run the above twice.
I have removed value of Alignment key (just left it empty). The icon has gone until now but I didn't install no updates yet. Will keep posting.
UPDATE Restoring VS2015 not only restored this button but also changed the way it is configured: now my method doesn't work. Moreover, removing the registry key no longer helps. Wrote to MS through this helpful tool.
The Visual Commander extension allows creation of extensions which can hook into events. One provided example is hiding the feedback icon.
// References: System.Xaml
public class E : VisualCommanderExt.IExtension
{
public void SetSite(EnvDTE80.DTE2 DTE, Microsoft.VisualStudio.Shell.Package package)
{
timer = new System.Windows.Threading.DispatcherTimer();
timer.Interval = System.TimeSpan.FromMilliseconds(1000);
timer.Tick += OnTimer;
timer.Start();
}
public void Close()
{
timer.Stop();
}
private void OnTimer(System.Object o, System.EventArgs a)
{
try
{
if (HideSignIn() && HideFeedback())
;
}
catch (System.Exception e)
{
}
}
private bool HideSignIn()
{
System.Windows.FrameworkElement e =
FindElement(System.Windows.Application.Current.MainWindow,
"PART_MenuBarFrameControlContainer");
if (e != null)
{
e.Visibility = System.Windows.Visibility.Collapsed;
return true;
}
return false;
}
private bool HideFeedback()
{
System.Windows.FrameworkElement e =
FindElement(System.Windows.Application.Current.MainWindow,
"PART_TitleBarFrameControlContainer");
if (e != null)
{
System.Windows.DependencyObject o1 =
System.Windows.Media.VisualTreeHelper.GetChild(e, 0);
System.Windows.DependencyObject o2 =
System.Windows.Media.VisualTreeHelper.GetChild(o1, 0);
System.Windows.DependencyObject o3 =
System.Windows.Media.VisualTreeHelper.GetChild(o2, 0);
if (System.Windows.Media.VisualTreeHelper.GetChildrenCount(o3) == 3)
{
System.Windows.DependencyObject o4 =
System.Windows.Media.VisualTreeHelper.GetChild(o3, 1);
(o4 as System.Windows.FrameworkElement).Visibility =
System.Windows.Visibility.Collapsed;
return true;
}
}
return false;
}
private System.Windows.FrameworkElement FindElement(System.Windows.Media.Visual v, string name)
{
if (v == null)
return null;
for (int i = 0; i < System.Windows.Media.VisualTreeHelper.GetChildrenCount(v); ++i)
{
System.Windows.Media.Visual child =
System.Windows.Media.VisualTreeHelper.GetChild(v, i) as
System.Windows.Media.Visual;
if (child != null)
{
System.Windows.FrameworkElement e =
child as System.Windows.FrameworkElement;
if (e != null && e.Name == name)
return e;
}
System.Windows.FrameworkElement result = FindElement(child, name);
if (result != null)
return result;
}
return null;
}
private System.Windows.Threading.DispatcherTimer timer;
}
Although, comparing this example with the hide publish button example it seems the OnTimer function should stop the timer once the icons have been hidden.
private void OnTimer(System.Object o, System.EventArgs a)
{
try
{
if (HideSignIn() && HideFeedback())
timer.Stop();
}
catch (System.Exception e)
{
}
}
This line of PowerShell removes the icon until an update is installed:
Set-ItemProperty -Path "HKCU:\Software\Microsoft\VisualStudio\14.0_Config\MainWindowFrameControls\{F66FBC48-9AE4-41DC-B1AF-0D64F0F54A07}" Package "{00000000-AA51-43B1-97EE-509A33B681F3}"
I use Addin in VS 2010 and VS Package (vsix) in VS 2012.
Addin and VSPackage uses common libraries.
I need detect if the library code (in execution time) is executed by Addin OR VSPackage.
Now, I have this code, but always true for Addin AND VSPackage
public static bool VSAddinVSPackageMode
{
get { return (System.Diagnostics.Process.GetCurrentProcess().ProcessName == "devenv"); }
}
I would like
public static bool VSAddinMode { get { ... } }
public static bool VSPackageMode { get { ... } }
Any suggestions for do best way about it?
Add-ins and packages are like different installers for the code. The actual code is the same and executed in the same VS process.
To detect the caller, if you know your host module names, you can walk the call stack until you find the add-in or package module.
You should probably not be using add-ins for Visual Studio 2010 or newer, but that's beside the point.
Add-Ins always use the same entry point. You could use a property like the following:
public bool VSAddinMode
{
get;
internal set;
}
Then, in your OnConnection method, set VSAddinMode = true; before calling other code.
VS Packages do not always have a single entry point, so the best way to implement VSPackageMode is the following:
public bool VSPackageMode
{
get { return !VSAddinMode; }
}
When you write a VS addin that proffers menu items to VS, it calls your QueryStatus implementation to check whether your menu items should be visible, enabled, etc.
My menu items are not appropriate to run during certain situations, e.g. when a build is happening. How do I detect whether there's a build running?
You're looking for the VsShellUtilities.IsSolutionBuilding method. An example of using it can be found the Managed Package Framework for Visual Studio 2010 (MPFProj10) in the ProjectNode class:
protected internal virtual bool IsCurrentStateASuppressCommandsMode()
{
if (VsShellUtilities.IsSolutionBuilding(this.Site))
{
return true;
}
DBGMODE dbgMode = VsShellUtilities.GetDebugMode(this.Site) & ~DBGMODE.DBGMODE_EncMask;
if (dbgMode == DBGMODE.DBGMODE_Run || dbgMode == DBGMODE.DBGMODE_Break)
{
return true;
}
return false;
}
i want to use ILspy debug a dll,as pic:
but it only can show two process:
but in vs2010,i can attach more process:
how to show w3wp.exe in ILspy? who can help me?
Running ILSpy as an administrator solved this problem for me.
From the ILSpy source code (ICSharpCode.ILSpy.Debugger.UI.AttachToProcessWindow):
Process currentProcess = Process.GetCurrentProcess();
foreach (Process process in Process.GetProcesses()) {
try {
if (process.HasExited) continue;
// Prevent attaching to our own process.
if (currentProcess.Id != process.Id) {
bool managed = false;
try {
var modules = process.Modules.Cast<ProcessModule>().Where(
m => m.ModuleName.StartsWith("mscor", StringComparison.OrdinalIgnoreCase));
managed = modules.Count() > 0;
} catch { }
if (managed) {
list.Add(new RunningProcess {
ProcessId = process.Id,
ProcessName = Path.GetFileName(process.MainModule.FileName),
FileName = process.MainModule.FileName,
WindowTitle = process.MainWindowTitle,
Managed = "Managed",
Process = process
});
}
}
} catch (Win32Exception) {
// Do nothing.
}
}
Seems relatively straight forward...
It is preview software, so perhaps there is a flaw in this algorithm for determining if a process uses managed code.
You might be able to move pass this issue just by downloading the source code and changing
bool managed = false;
to
bool managed = true;
and recompiling.
I don't have the full version of IIS7 installed so I can't attempt to recreate your issue, but I doubt I would have the same problem anyways because my visual studio development server shows up fine in ILSpy while yours does not. Perhaps there is something different about your environment that messes with the above algorithm.
32-bit vs 64-bit might also play some role