If I connect to my development machine via RDP and work with an asp.net solution, I have to enter my username and password for opening the projects web site (from within the rdp session). If I do the same localy on the development machine, no password is required.
The only solution to avoid this strange behaviour, is to deactivate NTLM-authentication in the project start options.
What is the reason for this strange behaviour? What is the difference when I use VS2010 in remote session instead of a local session?
Related
I'm a contractor working remotely on a legacy ASP.NET application. I'm struggling to stand up a local instance of the project due to the error SQL Exception - SQL Server does not exist or access denied. I suspect this is because of the use of Windows Authentication for the SQL databases backing the project.
Before I launch into a lot more detail I'll ask my question: what are my options to pass Windows credentials to an SQL server in an ASP.NET project built on OSX?
I believe I've proven this is possible with some steps I'll detail below, but the actual implementation in an ASP.NET project is escaping me due to my inexperience with everything .NET, and the many-fold differences between my setup and the typical dev.
Standard Dev Setup
The devs I'm working alongside are using Windows machines housed in their corporate domain, running Visual Studio 2012. Because they're already logged into their machines with the appropriate credentials, the use of Integrated Security=SSPI in the SQL connection string "just works".
My Setup
I'm running a Mac Mini outside of their corporate domain, and using Visual Studio in conjunction with Mono to support the .NET Framework-based project. Passing the SSPI option won't work out of the box because I'm not connected to any Active Directory. That said, I do have valid credentials to log into their network.
What's worked so far
I've proven that a connection to their network resources is possible:
When logged into a virtual Windows machine, I can connect to a shared drive on that network with the credentials I was provided.
I then set up that same shared drive on my Mac Mini with those same credentials.
Using SQL Pro for MSSQL, I was able to connect to the desired database using my credentials.
As I understand it, what I'm looking for can be accomplished on Windows with Credential Manager, so bottom line I think I'm looking for the equivalent solution on OSX that plays nicely with ASP.NET project as compiled by Visual Studio.
We have a Windows Server 2008 R2 box setup as a Terminal Server with Visual Studio 2012 installed on it for remote developers to be able to do development on our ASP.net systems.
We would like to be able to do debugging on out projects the same way we do when developing on our local machines using visual studios internal development server.
I am trying to start local debugging on an ASP.Net project (F5) in VS2012 - the project compiles - IE comes up with my localhost url and then it just spins with "connecting..." and the page never comes up.
Pulling up the same workspace on a local machine and debugging comes up just fine.
I've exhausted my google-fu on looking for solutions here and humbly ask you all for any insight.
Visual Studio works a little differently when you are debugging on a server. You don't really want to use VStudio to play/debug on a web server. You need to use the menu option "Debug", "Attach to process". There will be several processes running, so it might take a few tries to find the right process.
Be careful though. Because your break-points will actually freeze IIS for the entire server. It could be a pretty big inconvenience for everyone who is using IIS at the time.
If you are trying to debug the project from your IIS server, you need to verify if the account has Administrator rights, also if the project has been deployed with its source files, you can attach the process (maybe it is w3wp.exe) in Visual Studio and debug it.
Another way is to open the solution using Visual Studio and change in the web project's property the server: Use Visual Studio Development Server.
Let me know more info about your scenario to provide you more paths.
What I would do is attach to the IIS process on the server: http://msdn.microsoft.com/en-us/library/vstudio/3s68z0b3.aspx you can even do this off your machine.
make sure debug is enabled in web.config for that app and you've mounted the remote project. Add a break point, debug by attaching to the IIS app pool process & it'll trigger the break point.
I was able to Attach Process to the SPUCWorkerProcess.exe even though it's a farm solution and not a sandbox solution
I have a bug in a website that is using trusted connect to access a database. I do not get the error when debugging locally. I believe this is down to the specific permissions assigned to my personal windows account.
Is there an easy way to run the website (visual studio 10 debugger/Casini) as the app pool identity in question and step through?
You can actualy debug IIS process using Visual Studio.
Go to menu "Tools" and select "Attach to process..."
Make sure you check "Show processes from all users". You should be looking for "w3wp.exe".
In this way you can attach and debug process runing on IIS (your app).
My web service needs to open some files located on a remote computer.
From Windows I can do the authentication so I can see those files using the File Explorer.
If I try to open the files from my Web Service while it's running using Visual Studio (ASP.NET Development Server) it also works.
However, if I do everything from IIS it doesn't.
In order to find out where is the problem what I did was to run a network sniffer and I found out that when using IIS, the system will try to use the account 'ASPNET' to login into those remote computers which will obviously fail.
However this doesn't happen if I run from the IDE (Using the ASP.NET Development Server)
I found out that if I use Impersonation for accessing this it will work, the problem is I need to have the same account names on the computer running IIS so I would rather not to do that.
Why is it working from the ASP.NET Development Server and not from IIS? Is there a way to give full access to the ASPNET account?
Thanks and hopefully somebody will be able to help with this. I don't know what else to try...
Any request on IIS is served by the ASPNET user. So the user ASPNET is working. I think you are using XP. On Win2K3 etc, the user is Network Service
But the Cassini (Visual Studio Dev server) runs under the current logged in user.
So the difference is. You need to use impersonation for your need.
I am developing a remote control application where a client (aspx page in a browser) can request a server to "launch a notepad" (for testing purpose, for real life, turning off a light bulb, etc). So I created a dll with a simple function for launching the notepad (on the server side) and dropped this dll in the root bin folder.
It worked fine when the aspx page is running under ASP.NET development server (launched from Visual Studio). But when I tested the same aspx page under a FireFox browser, it did not work (launch the notepad) even though it did call for the same function (I stepped through in debugger).
Is this a permission issue? How do I set this up in IIS manager, or even better in web.config?
Please help.
Yes, it sounds like a permission issue.
The application pool in IIS 7 that your site is running under is probably using the default identity, which is the most restrictive. You can change the identity in IIS Manager by right-clicking on the app pool (probably called DefaultAppPool) and selecting Advanced Settings. From there change the Identity value to Local Service or Network Service. If neither of those work, making it Local System should allow your page to work.
I assume the Visual Studio integrated web server runs under the context of the account you are logged in with on the machine, which likely has a lot more rights.
When you say:
it did not work (launch the notepad)
Did you mean it through an exception or you didn't see a notepad window open. If it was a permissions issue I would expect you that you would get an exception. Chris is right on when he says:
The application pool in IIS 7 that
your site is running under is probably
using the default identity, which is
the most restrictive.
and
I assume the Visual Studio integrated
web server runs under the context of
the account you are logged in with on
the machine, which likely has a lot
more rights.
and if this is a permissions issue he is right on. However, the user your running under (when not debugging in Visual Studio) most likely cannot access the desktop of the logged in user. Maybe you should try your test with an app that doesn't need to interact with the desktop.