DevFC.exe (Development Fabric) for Windows Azure Crashes - c#

Whenever I debug my application (ASP.NET Web Application converted to Web Role), I am able to get to the login page. I go ahead and sign in, debug through that and it seems to work fine, but as soon as it takes me to the landing page after login, DevFC.exe stops working with the error:
An unhandled exception ('System.Net.Sockets.SocketException') occurred in DevFC.exe [8072].
Now, I've searched for the issue and have seen something about DevFC.exe crashing due to VMWare Workstation that listens on the same port (12000) and HTC Sync that also listens on that port. I have neither of those applications on my machine, so I am lost here. Using TCPView (from Sysinternals), I find no other application using that port.
The one thing I do notice is that [System Process] goes crazy creating connections to localhost:12000 once DevFC.exe gets started.
Anyone have some insight on this?

This might sound ridiculous but restarting your machine might solve the issue. If that doesn't work, try your project on a different machine. If the project works then there is an issue with your primary machine try uninstalling then reinstalling the Azure SDK. If the devFabric still crashes on the secondary machine then it's something related to your project.

You might want to take a look at the logs created in the DevFC folder here: %localappdata%\dftemp\DevFCLogs (C:\Users\[user]\AppData\Local\dftmp\DevFCLogs). This will hopefully shed light on the actual error (which in my case, was a conflict on port 12001. Ran netstat -ab afterwards and found it was vmware-hostd.exe. This is a service included with VMWare Workstation 8. I know you said you don't have that, but you may have some other conflicting software).
See this thread as well for more detail.
http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/7e205afd-4b9a-4387-8e10-99e4b8f27788

Related

New PrintServer object fails, "printer name is invalid"

I'm migrating a working ASP.NET web application from WS2008R2 to WS2016, but the same happens on WS2012R2. It fails when executing:
new System.Printing.PrintServer(#"\\printserver");
It throws:
System.Exception: An exception occurred while creating the PrintServer
object. Win32 error: The printer name is invalid.
printserver is not an alias but a hostname. It loads correctly on Windows Explorer. The same line works fine on a regular Console Application when compiling under the same .NET 4.5.2, and also in PowerShell when loading the System.Printing.dll. The GAC shows the right assemblies, and I've also added them manually just in case.
I've set the same application pool configuration settings from the working WS2008 (disabled 32-bit applications and Classic mode), but I've tried different combinations in any case. The application pool runs under the same domain service account on both old and new.
As some user also suggested, I've installed the Print and Document services role, even though the old server doesn't have it, but to no avail.
I'm out of ideas, any kind of help would be greatly appreciated. Thanks!
Not really a solution... But I "fixed" this by changing the path of the website in IIS manager back and forth a couple of times. Yes, after a year of trying all I could think of on several servers.
Anyway, not sure what exactly unblocked the situation, but it works for me.

Deployment to Remote Machine failed - UWP Debugging

I am currently attempting to deploy an app to a Windows 10 tablet running the Creator's Update, over my local network. When I select remote machine and enter my debug settings, I can discover the tablet on my network, and get its address and Authentication mode automatically.
However, when I try to deploy, I get this error:
DEP6957 : Failed to connect to device using Universal Authentication. Please verify the correct remote authentication mode is specified in the project debug settings. 0x8007274C: The network event being waited on triggered an error.
As far as I can tell from the documentation that I've read, this process should be more or less plug and play since the Creator's Update, can anyone explain what I might be doing wrong, or what might be going wrong?
Listed here are my debug settings currently in use.
Update: Since its not the solution I was looking for, I'm not adding it as an answer, but if anyone comes across this looking for a fix and no one has suggested one, the way I ended up working through this is just downloading the remote debugger to the tablet and running the old method for C# apps. I never did find out why the UWP method didn't work.

Application can't find Local IIS Server

I have client-server .net application, WCF communication with IIS.
During development I encountered a strange phenomenon:
Once in a while, when I run my application without debug and press a button - it seems like the server doesn't respond to the action.
Then I turn to check the same action on debug mode, and when I try to attach the service to process in oder to debug it - I can't find the w3wp.exe process, which is surely active !
But when I open the inetmgr (IIS Manager) and press Browse to the service site - suddenly the service is found in the Attach to process list on VS, and everything continues to work - with or without debug mode - as if nothing had happened.......
Does anyone experienced something similar, or have any assumption why is this happening?
I am concerned that similar incidents can affect the stability of my system.
Note: Perhaps the phenomenon above occurs after I update the client service reference, but I'm not pretty sure.
Thanks!
I'm not exactly if I will answer your question since it's not clear but let me put answer anyway:
I sometimes get an error in running WCF on my machine and this because I have my host running Local IIS then when I change it to IISExpress it runs without issues.
To change this, right click the project -> properties-> open web tab, locate servers and select IIS Express in dropdown. See image
To understand the difference between the two you can check: http://weblogs.asp.net/scottgu/introducing-iis-express

Operation is Not Supported - System.Reflection.Assembly.LoadFile()

Just installed our application on a client's server, and we are seeing an error that we have never seen before. This program runs on hundreds of computers and servers around the world, and apparently this one is different. Our client is fairly security conscious, so I'm guessing we need to have them unlock something, but no idea where to start. Google search of the issue only gives me a bunch of PowerShell references.
When calling System.Reflection.Assembly.LoadFile() to load in a DLL, we receive an "Operation is not supported" error.
This is a .NET 4.0 C# application.
Thanks
Went to each non-working DLL, properties, UNBLOCK. Restarted our service, and everything started working.

Nod32 causing LocalHost (ASP.NET Development Server) "Connection Interrupted" Problem

I'm quoting myself on a previous question I asked to further explain:
"I'm trying to run a freshly created ASP.NET Website using C#, however when I do so it launches FireFox and attempts to connect to http://localhost:1295/WebSite1/Default.aspx (for example), but after about 10-15 seconds it displays a "Connection Interrupted - The connection to the server was reset while the page was loading." Error.
This issue is also present with older ASP.NET C# pages/Web Services I've built in the past, nothing is actually running off the ASP.NET Development server."
This is the problem that was occuring, that is before I noticed every time I ran the website, the notification for the ASP.NET Server-startup showed one port (1130 for example), and when the website failed to load; it turns out it was attempting to load the site on another port (In this case, 1128). It was suggested that an anti-virus program could have caused this kind of redirection; low and behold uninstalling Nod32 fixed the problem!
So my question is: Has anyone found a way to create an exception or remove this functionality from Nod32?
Within Nod32 enter the Advanced Setup options, and turn off protocol filtering.
It's a known problem with NOD32. Looks like it's IMON module (protocol filter) accidentally does some modifications of TCP packets that go through it.
The solution is to either turn it off, or use a different software.

Categories