We Keep Coding

how do I get the Omnisharp extension to work in Visual Studio Code

In Visual Studio Code I tried to install the Omnisharp extension so that I can get formatting (among other things).
this is the c# log: Installing C# dependencies...
Platform: win32, x86_64
Downloading package 'OmniSharp for Windows (.NET 4.6 / x64)' Retrying from 'https://omnisharpdownload.blob.core.windows.net/ext/omnisharp-win-x64-1.32.8.zip' Failed at stage: downloadAndInstallPackages
Error: connect ETIMEDOUT 93.184.215.201:443
You can also tell the extension didn't install by the Omnisharp log error:
Starting OmniSharp server at 1/9/2019, 4:17:59 PM
Target: c:\Users[myUserId]\source\project-folder
OmniSharp server started.
Path: C:\Users[myUserId].vscode\extensions\ms-vscode.csharp-1.17.1.omnisharp\1.32.8\OmniSharp.exe
PID: 15188
The system cannot find the path specified.
[ERROR] Error: OmniSharp server load timed out. Use the 'omnisharp.projectLoadTimeout' setting to override the default delay (one minute).
It seems like the version 1.32.8 is not available, but https://omnisharpdownload.blob.core.windows.net/ext/omnisharp-win-x64-1.30.1.zip is.
I downloaded the package, extracted filed, and tried to placed the folder where it's expected: C:\Users[myUserId].vscode\extensions\ms-vscode.csharp-1.17.1.omnisharp\1.30.1\OmniSharp.exe -- but windows doesn't allow folder names starting with a dot in this location. I thought I had figured out a solution and I didn't.

I had the problem previously. So did setup proxy and other at settings.json.
But now in new VS Code, i was getting same problem weirdly.
Finaly when i emptied out the settings.json file (deleted all the settings) VS code is working.
It automatically downloads C# and other extentions.
So, give it a try, if you had some settings put there for previous versions of VS Code, you got to remove(comment) them to check if thats cuasing problems.
[You dont have proxy, but if someone have, 'yes of course proxy needed to setup for .npmrc and enviroment variables at cmd as internet is necessary to download files]

This article has a section at the end about installing downloaded extension as vsix files. It also mentions the error you described and about how it could be proxy related. It is a somewhat long article... but I hope this helps.
https://code.visualstudio.com/docs/editor/extension-gallery
"Can I download an extension directly from the Marketplace?
Some users prefer to download an extension once from the Marketplace and then install it multiple times from a local share. This is useful when there are connectivity concerns or if your development team wants to use a fixed set of extensions.
To download an extension, navigate to the details page for the specific extension within the Marketplace. On that page, there is a Download Extension link in the Resources section which is located on the right hand side of the page.
Once downloaded, you can then install the extension via the Install from VSIX command in the Extensions view command drop-down."

What worked for me was this:
(press crtl + shift + P) then choose Preferences > Open settings
Comment these lines out if they are there:
// "http.proxySupport": "on",
// "http.proxyAuthorization": null,
After I did this, the extension was able to use the proxy settings, and the extension downloaded and worked!

The installation should be easier with VSCode 1.61 (Sept. 2021) because, as OmniSharp/omnisharp-vscode issue 4775 mentions:
VS Code now supports platform specific extensions.
This should be very useful for C# since currently you download platform binaries after activation.
As detailed in Publishing Extensions / Platform-specific extensions:
Extensions can publish different VSIXs for each platform (Windows, Linux, macOS) VS Code is running on.
This is useful if your extension has platform-specific libraries or dependencies, so you can control the exact binaries that are included in a platform package.
A common use case is the use of native node modules.
When installing a platform-specific extension, VS Code (starting from version 1.61.0) looks for the extension package that matches the current platform.
If no package has been published for the platform, the extension will appear as disabled and can not be installed.
Therefore, you need to publish a package for each and every platform that your extension supports. To meet this requirement, we are providing tooling to help make this potentially repetitive process easier.
This is followed by the 2018 microsoft/vscode issue 23251

C# Visual Studio Service Debugging "The breakpoint will not currently be hit. No Symbols have been loaded for this document"

New to Visual Studio and new to C#. Building a C# windows service called Transactional Messaging in Visual Studio 2017, which is dependent on a project called Outbound Messaging. When I start debugging and try adding breakpoints on the Outbound Messaging files, I get
"The breakpoint will not currently be hit. No Symbols have been loaded
for this document"
From what I can tell, VS is only unable to load the pdb files for: log4net.dll, Castle.Windsor.dll, and Castle.Core.dll. I don't have this issue with adding breakpoints to files in the Transactional Messaging Service. I haven't been able to identify behavior patterns or a permanent fix, so at this point the error seems random. One minute I think I've found a fix, and when I try using that fix on the same error later in the day I have no luck. I am suspicious of a recent power outage that shut my computer down unexpectedly since it looks like pdb files can be cached, but have been told that would be a long shot.
Steps I follow to debug the service:
Stop Transactional Messaging Service via windows services applet
Uninstall Transactional Messaging Service via VS command line using installutil /u TransactionalMessaging.exe in the Debug folder
Clean Transactional Messaging Solution in Visual Studio
Build Transactional Messaging Solution in Visual Studio (at one point a fix was to right click on each aspect of the solution in the solution explorer and build that individually)
Install the Transactional Messaging Service via VS command line using installutil TransactionalMessaging.exe in the Debug folder
Start the Transactional Messaging Service via windows service applet
In VS, Debug > attach to process > Transactional Messaging
Try adding breakpoints to files in Outbound Messaging service which gets me the above error.
Steps I've tried to solve this error:
Debug > Windows > Modules to manually load each module's symbols (pdb files for log4net.dll, Castle.Windsor.dll, and Castle.Core.dll cannot be found)
picture of modules
Completely delete bin and obj folder between steps 2 and 3 above
Project > Project properties > Build > Advanced > Debugging Information: full (for both Transactional Messaging and Outbound Messaging)
I'm not sure if this is a lack of understanding of VS, C#, or the code base. Any insight is appreciated, I'm past the googling stage and posting a new question as a last resort.

I usually get this message when I have changed code in a project A and forgot to compile it.
The other project B, which references project A, has the up-to-date source code of A on the screen, but started with an outdated assembly of A. So it cannot enable breakpoints because the code does not match the assembly.
There's one more thing, which in my opinion is a bug and a pain in the ass, but according to MS is by design (I have asked them):
Since Visual Studio 2015, the compilation of project B does NOT automatically include modified referenced assemblies, which in this example is assembly A. There is a local copy of A somewhere in B, which is used instead. Same result as above: up-to-date code, but outdated assembly.
Instead of compiling, you have to rebuild it!
There's another one more thing:
You have to compile for DEBUG mode. In Release mode, the default project settings do not allow proper debugging, like they did in VS 2008 for example.

You can not attach the debugger, because you are lacking the right to do so. You can get this right only be flipping a certain bit in the registry.
See my earlier Answer:
Also start VisualStudio as Administrator and allow, that a process can
automatically be debugged by a different user:
reg add "HKCR\AppID\{E62A7A31-6025-408E-87F6-81AEB0DC9347}" /v AppIDFlags /t REG_DWORD /d 8 /f

If nothing help from above than make sure your files are open from the relevant project, not from another (old) one.
Example:
You working on a project, close the VS, but you left files (tabs) open in VS.
Copy your project to a new folder and open solution. The files (tabs) will load from the old directory and if you want to debug then you cannot debug until you close them and reload them from the current folder.
I was very close to reinstall my VS because nothing helped for me from another answers, but fortunately I realised this in my project and I can debug now.

Mono Pkg-Config.exe Keeps Crashing?

I'm new to Mono - thought I'd give cross platform a try - my main IDE is Visual Studio and so the process of building applications through the command prompt is a bit foreign to me.
I was following the Mono Basics tutorial, and have gotten to the point where it says Winforms Hello World. I copied the code provided and saved it to a .cs file (on the Desktop).
I then opened up a command prompt and pointed it towards the Desktop directory. I ran the command:
mcs hello.cs -pkg:dotnet
And the result was:
The console told me that it was a CS8027 error but nothing else.
I have 3 environment variables that I added, with no fix:
PATH -> path to mono\bin
PATH -> path to mono\lib\pkgconfig
PKG_CONFIG_PATH -> path to mono\lib\pkgconfig
This happens whenever I try to use pkg-config.exe (tried to use pkg-config.exe --list-all but the same problem arose).
I've checked other answers/questions about the CS8027 error but the solutions did not help - it still crashes every time!

Had the same problem. I had all the proper VC++ runtimes installed, but still crashed.
pkg-config.exe references librares (.dll) that are compiled in different versions of .Net. Your PATH (or pkg-config itself) might be referencing a different version than the one the .dll uses, or not have it at all.
pkg-config is a short-hand anyway. I fixed it by explicitly including the .dll I'm referencing using the proper version of .Net for me:
mcs hello.cs -r:"C:\Program Files\Mono\lib\mono\4.5-api\System.Windows.Forms.dll"

pkg-config is built with a different version of MSVC to Mono itself. You need the 32-bit VC++12 runtime installed for it to work. That ought to be included with mono.msi, as per https://github.com/mono/release/commit/8394dcc254510977c3e654abf916a48c6c6894fb
If you check the Windows event log, under Applications, you might get more information on what didn't work.

I had this problem, could help some.
D:\Code\Mono>mcs hello.cs -pkg:dotnet
error CS8027: Error running pkg-config. Check the above output.
I needed to download the following DLL:s from https://www.dll-files.com/
libiconv-2.dll
libgcc_s_sjlj-1.dll
libintl-8.dll
libglib-2.0-0.dll
Put them in C:\Program Files\Mono\bin
All DLLs should be 32 bits even if Mono was 64 bits.

In my system the problem was the empty space inside the path of install and how that is managed inside of the pc files.
A workaround is to edit the pc files to change the prefix entry to the short path. In my system:
prefix=C:/PROGRA~1/Mono
instead of
prefix=${pcfiledir}/../..

UWP app WACK test fails & outputs debug irrespective of chosen settings

I am trying to create a package of my UWP app and put it through a WACK test.
Windows App Certification Kit - Test Results is FAIL. I think it's because VS2015 is outputting a debug build irrespective of the settings i've chosen.
Has anyone come across this problem before?
Is visual studio ignoring my settings, or does my project include a library that's not going to pass WACK?
'Release' is selected both in the build menu and in Output Package dialogue.
JSON.net and EF7 only, both are UWP compatiable. Tasks and DataAccess are a background task and a class library.
File C:\Program Files\WindowsApps\f0679d56-bdc0-4305-837e-16b5560c7c41_1.0.14.0_x86__ade4xr40r36he\coreclr.dll has failed the AppContainerCheck check.
File C:\Program Files\WindowsApps\f0679d56-bdc0-4305-837e-16b5560c7c41_1.0.14.0_x86__ade4xr40r36he\dbgshim.dll has failed the AppContainerCheck check.
File C:\Program Files\WindowsApps\f0679d56-bdc0-4305-837e-16b5560c7c41_1.0.14.0_x86__ade4xr40r36he\mscordaccore.dll has failed the AppContainerCheck check.
File C:\Program Files\WindowsApps\f0679d56-bdc0-4305-837e-16b5560c7c41_1.0.14.0_x86__ade4xr40r36he\mscordbi.dll has failed the AppContainerCheck check.

i also have the same issue and it is caused due to EntityFreamework.Commands reference. When you building the code for store package or release mode just remove all references of EntityFramework.commands by uninstalling from nuget.
that should help to get rid of those errors. for more information please go here. let me know how it went.. all the best.

I am now using VS2015 preview 2 and everything is building with it just fine. I get no errors in the WACK.
Microsoft just decided to release .net native a year before it could actually compile things properly.

Migrating Visual Studio 2005 sln to 2008, warning with vc98 paths in LIB environment variable, how to fix?

I'm migrating a solution from visual studio 2005 to visual studio 2008. When I build the solution in 2005, I don't have any issues. However, after I use devenv.exe /Upgrade and then use msbuild on the solution, I get the following warnings:
CSC : warning CS1668: Invalid search path '\vc98\lib' specified in 'LIB environment variable' -- 'The system cannot find the path specified.'
CSC : warning CS1668: Invalid search path '\vc98\mfc\lib' specified in 'LIB environment variable' -- 'The system cannot find the path specified. '
CSC : warning CS1668: Invalid search path 'c:\program files\microsoft visual studio 9.0\vc\platformsdk\lib' specified in 'LIB environment variable' -- 'The system cannot find the path specified.'
I have checked http://social.msdn.microsoft.com/Forums/en-US/Vsexpressinstall/thread/3f875480-fee2-4bc3-b829-95e220b22a01 and it doesn't offer me any help because my LIB and INCLUDE environment variables are not set either in the user vars or the system vars. I've looked at Studio's Tools > Options > Projects and Solutions> VC++ Directories and there's nothing that references anything old:
Library Files:
$(VCInstallDir)lib
$(VCInstallDir)atlmfc\lib
$(VCInstallDir)atlmfc\lib\i386
$(WindowsSdkDir)\lib
$(FrameworkSDKDir)lib
$(VSInstallDir)
$(VSInstallDir)lib
Include files:
$(VCInstallDir)include
$(VCInstallDir)atlmfc\include
$(WindowsSdkDir)include
$(FrameworkSDKDir)include
I used diagnostic output so that I could see exactly what the LIB variable includes when being called:
lib = c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;C:\Program Files\Microsoft SDKs\Windows\v6.0A\lib;\vc98\lib;\vc98\mfc\lib;c:\program files\microsoft visual studio 9.0\vc\platformsdk\lib;c:\program files\microsoft visual studio 9.0\vc\lib;c:\program files\microsoft visual studio 9.0\vc\atlmfc\lib;
LIBPATH = c:\Windows\Microsoft.NET\Framework\v3.5;c:\Windows\Microsoft.NET\Framework\v2.0.50727;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB
So if that vc98 is NOT in my env vars, or my studio settings and vc98 isn't even installed (nor the redist), where is that path coming from? What process sets up the LIB env var like that?

Found on MSDN:
Yes this is a known issue that occurs
to some people. Look carefully in
your LIB path. Right after ATLMFC, V,
SDK -> \vc98\lib. Delete this entry
(and the one that follows). If the
LIB is a user variable then you'll
need to restart VS or perhaps log off
and back on. If it is a system
variable then you'll have to reboot.
Your error should then go away.

Here is the solution
http://msdn.microsoft.com/en-us/library/tcbs315h(v=vs.80).aspx
its refer to the LIB entry at Environment Variables

Seems like you have covered most things here, so the only thing I can think of is inherited property sheets.
They are specified in the vcproj XML (or you can check the Property Manager in the IDE):
<VisualStudioProject>
<Configurations>
<Configuration InheritedPropertySheets="stuff.vsprops">...
If you do have some inherited property sheets, go have a look in the file and see if you have any vc98 lib paths set explicitly?

I am wondering if this could be due to the change in using the compiler switches /MT and /MTd from /ML and /MLd which occured for VS2005 relating to C runtime libraries?
Refer to here and see if it helps:
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

I'm having a very similar issue with C# projects in VS.NET2010. It appears only to affect those projects which import C++/CLI projects. The projects are still set to compile using the v9.0 toolset(C++, C++/CLI) and .NET 3.5 (C++/CLI, C#). Have you had any luck finding the source of the problem?
I worked around it by adding warning 1668 to the ignored warnings list in the properties of the affected projects. That's not ideal, but better than spam in my warnings list.