Develop Reference

Attempting to run C# on cloud9 IDE but receiving errors

I’m new to Cloud9 and I’m facing some issues.
I’m attempting to run the C# code on the IDE and am failing to do so, I think I know why but I cant seem to be able to resolve the issue.
The picture uploaded below should have everything needed to solve the problem
enter image description here
Upon further research, I found a link that goes through a step by step process on how to install .NET core. However, I'm having issues, with setting the project template using this code for the terminal dotnet new console -lang C#
It starts decompressing then stops at 99%. (as indicated in image below) The first error that pops up states that System.IO.IOException: No space left on device not sure what to do with this though.
https://imgur.com/a/30Vh6Eu
I kept on attempting the same code and it has managed to complete the decompressing stage only to start resetting again at the Expanding stage. (Refer to image below).
https://imgur.com/a/UMtpYow

Run C# is not yet supported on Cloud9 IDE
https://docs.c9.io/docs/supported-languages

I think #shingo is correct to say C# is not supported BY DEFAULT. It is possible, however, to make it happen as shown in the links below, but not advisable as there is little help out there. I wouldn't do it if I were you.
blog help
youtube
aws documentation not specifically about c# but related

Media Foundation: ReadSample - Access Violation Exception

Context: I'm looking at the effects of down sampling, then up sampling video files. I'm using Media Foundation .NET to expose MF in C#. Program currently goes through following process:
Take a high res video and read in each frame (SourceReader & ReadSample)
Down sample using custom code that manipulates at the byte level
Write the down sampled data to a new, lower res video file (using SinkWriter)
Repeat for a range of resolutions supported by Media Foundation
Read down sampled videos back in and up sample to the next higher resolution in the list below, again using custom code that manipulates each byte
Write the new data to a higher res file (again using SinkWriter)
Resolutions I'm using are:
2560,1440
2346,1320
2134,1200
1920,1080
1706,960
1494,840
1280,720
1068,600
854,480
640,360
428,240
214,120
Current situation: This works almost perfectly. I run through the down sample process and have 11 down sampled video files (one at each resolution in the list above), plus the original 1440p video. I then read in each of those 11 videos and up sample. It works for 10 of them.
The problem: when I try to take the (1280,720) video to up sample to (1494,840), I get:
System.AccessViolationException: 'Attempted to read or write protected memory. This is often an indication that other memory is corrupt.'
... when I try to read in the first frame. I can't figure out why. The SourceReader configures fine (at least, no error returns). I do things like Marshal.Copy to get the sampled frame data into managed memory space, which I initially assumed was the problem. Code doesn't get that far though - just errors as soon as I try to read the first frame sample. ReadSample is in a Try...Catch block, but exception remains unhandled, so no other error information returned.
I don't want to just start pasting in unhelpful code, so please let me know what is useful to see and I'll add to the question. Most of the code has been taken from MS tutorials for SourceReader and SinkWriter. Also worth keeping in mind that this works in most situations, so code isn't 'broken' as such.
I've tried compiling in Release and Debug, x86 and x64. Also tried Suppressing JIT Optimisation in Visual Studio options.
Any ideas on where to look next?

Turns out this is a problem with the Media Foundation .NET interface, not the underlying MF framework. I built a small test program in C++ that implemented key parts of the code and it went through fine.
Not sure why Media Foundation .NET was causing problems, but the solution was just to set attribute:
MF_SOURCE_READER_ENABLE_ADVANCED_VIDEO_PROCESSING
rather than
MF_SOURCE_READER_ENABLE_VIDEO_PROCESSING
With advanced processing on, it behaves properly.

Very strange C# RemotingException

When I compile and run my program in Debug mode, everything works as intended. However, when I compile and run in Release mode, things get a little... strange. I receive the following exception if I run the Release mode executable
RemotingException occurred: The async result object is null or of an
unexpected type.
We do use .NET remoting in our application, however, I can confirm this is not a problem with any of my remote calls. This is happening right when I open the program, before I can even step into the Main() method. I have not really been able to find any help on the internet regarding this particular exception/message combination, other than a suggestion about the path being too long (but neither my working copy or the installed copy should have paths long enough to trigger this). Any assistance on this is greatly appreciated, as I'm not entirely sure how to proceed with this error.

Check here: mystery RemotingException raised when changing Platform Target to Any CPU
It seems to change the paths to the DLL's you want to access. Take a look at the paths in the linked question. They are well over 127 chars, and there is nothing you can do about it.
Example:
'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.HostingProcess.Utilities.Sync\10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.HostingProcess.Utilities.Sync.dll
EDIT: Try changing to "x86" and see if the error goes away.

Locating the source of managed exceptions that aren't coming directly from my code?

I apologize in advance if this is really a Super User question... I just wasn't sure, but this seems more on the dev. side than on the tech support side. :)
This isn't necessarily a problem, but it does actually drive me totally bonkers on my system. It also only happens on my computer.
When I launch any application, even a blank WPF application, I see four exceptions:
A first chance exception of type 'System.IO.DirectoryNotFoundException' occurred in PresentationCore.dll
A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
A first chance exception of type 'System.InvalidOperationException' occurred in PresentationCore.dll
To figure out where these are coming from, I then set VS2008 to break on any thrown CLR exceptions, and here is the information:
Exception #1:
Cannot find a part of the path 'D:\Dell\Reader2.0\SPLASH.SYS\fonts\AscenderUni.ttf'.
Exception #2:
Culture name 'ug' is not supported.
Parameter name: name
Exception #3:
Culture name 'ug' is not supported.
Parameter name: name
Exception #4:
There is no registered CultureInfo with the IetfLanguageTag 'ug'.
I've poked through Process Monitor and Process Explorer. Process Monitor shows that my application is doing a RegQueryValue, which I'm certainly not responsible for... but some DLL (presumably from Dell crapware) is getting loaded by my process and is reading this regkey. I then looked at Process Explorer, hoping to see which DLLs my application is loading, but can't find that info. I then tried PrcView and saw the modules my application was loading.
I was surprised to see how many other modules were getting loaded, but I didn't see anything Dell related. I'm also wondering how it is possible that a Norton Internet Security DLL got loaded into my process, but I assume that's intended and something special that Norton does to ensure that a process is safe to execute.
What else can I do to identify and remove where these exceptions are coming from?
UPDATE
Not sure if it's confusing what I'm getting at here. This exception is raised in a DLL that my application loads for some reason (I don't reference anything Dell-related from my project). I've now uninstalled that app, and I still get the stupid exceptions. It's all technically fine because the exception is handled somewhere, presumably within that DLL, but I'm just annoyed because four extra messages (actually 8, since I have to close two dialogs per exception) pop up when I run my application. Call me lazy, but I never asked this damn DLL to load in the first place. :)
Perhaps now it's time to use msconfig to start disabling some Dell services. I'll play with that later when I actually have free time.

No file corruption. As I've been trying to hunt this one down for a while, I figured out what happened. Somewhere along the way, a font was installed with Uighur culture, which is, apparently a Turkish/Chinese culture (as best as I can tell), and their CultureInfo tag? "ug". When the fonts were cached, the system was attempting to load the Uighur culture. Sadly, my installation of Windows seems to be conspicuously missing this culture in Windows. Knowing that I won't be using the culture on my machine anytime soon, I followed the directions on MSDN to create and install a new culture.
Though the error won't hurt anything major. It is just a first chance exception, after all, it was annoying the crap out of me. So here's what I did.
Create a new console app.
Add a reference to sysglobal.
Add the following code:
var culture = new CultureAndRegionInfoBuilder("ug", CultureAndRegionModifiers.None);
var ci = new CultureInfo("en-US");
var ri = new RegionInfo("US");
culture.LoadDataFromCultureInfo(ci);
culture.LoadDataFromRegionInfo(ri);
culture.Register();
Build.
From Windows Explorer (you need admin privileges to do this), run the compiled executable as administrator.
If all goes well, there should now be a file in C:\windows\Globalization called "ug.nlp".
You shouldn't receive that message again.

I had the same problem.
It disappear after I did:
Clear the WPF font cache and restarted Visual Studio.
Clear the cache: http://support.microsoft.com/kb/937135
Éric

It is very unlikely to be the shovel-ware on your machine. These DLLs need to inject themselves also into non-managed programs, they have to be written in a language that doesn't depend on the CLR, like C or C++. And accordingly cannot generate managed exceptions.
These exceptions look like machine configuration problems to me. Junk in your registry. The bad culture name (sounds like "us" got corrupted to "ug") generates three of them, the font is probably listed in the registry but missing from the disk.
Short from a OS reinstall, you could possibly diagnose this by using both ProcMon and the debugger. Use Debug + Exceptions, Thrown checkbox to force the debugger to stop on the first-chance exception. When it hits, switch to ProcMon, the registry key or file should be visible very near the end of the trace.

With leads from the above answers I was able to solve this issue by deleting the font "Microsoft Uighur Regular"

First chance exceptions are normal - these are displayed whenever an exception is thrown, whether it was handled or not. They exist so you can go into your code and find out why they are thrown.
However, if the exception has been handled, there is no problem and execution will resume.
If the exception was not handled, a second chance exception will be caught by the debugger and execution will halt.
This is normal and shouldn't be of concern. You can always hide them - see this question and answers for more details.
In regards to the actual exceptions - there is some code (third party or your own) that is trying to access a ttf in the mentioned directory, this cannot be found, hence the exception (which was handled, so no problem).
The other exceptions are due to create a non existing CultureInfo (ug) - perhaps this is supposed to be uk? Check configuration and code for this.
These values may be configured in the registry.

VB control crashes my app

I am using this - otherwise excellent - vb tab control in one of my c# apps. When the app using it is installed on another machine, Windows tells the user in its usual friendly and descriptive manner that "The application encountered a problem and needs to close". I guess the control has some hidden vb-related dependency, but what can that be?
Any ideas guys?

Since the tab control appears to be managed code as well, your 'crash' is most likely an unhandled .NET exception.
Looking at the error details (by expanding the error dialog using the button provided for that purpose...) should give you the exception message, which should give you an idea of what's going on. If it's a missing dependency DLL, the name should be included in the message.
To get the full exception, including the stack trace, one of the following should work:
Least effort: in the first line of your own managed code, add an unhandled exception handler which shows the full exception in a message box or logs it to a file prior to rethrowing it
Medium effort: attach a debugger to the process on the client machine. If it's on your local network, setting up remote debugging should be trivial, and should also allow you to debug exceptions that occur prior to your first line of code executing (which may very well be the case if the error is binding-related...)
Most effort: obtain the crash dump file from the client machine, and look at the managed exception using Windbg and the SOS debugging extensions. Getting productive with the tools involved will take some time, but on the plus side will teach you valuable debug ninja skills that will allow you to tackle pretty much any 'mysterious crash'...
BTW, all standard 'VB dependencies' are part of the default .NET Framework install, so that's not your problem -- only the exact exception (and possibly stack trace) will tell you what's going on.

Click the 'What data does this error report contain?' button and there will be more descriptive info. (i.e. type of the thrown exception, module etc.).
For additional info see Dr. Watson vs. CLR.

Is the dll containing the control distributed with your app? Perhaps you have a dependancy in the GAC thay you are missing?