迁移自Mobile Service的App Service代码部署至新实例遇数据库访问异常

Hey there, I’ve tackled similar issues when moving legacy Mobile Service code to fresh App Services, so let’s walk through what’s likely causing that Error: Internal Server Error and how to get your App Service (B) working properly.

Common Causes & Fixes #

1. Missing or Incorrect Connection String #

Mobile Services rely on a specific connection string name that your old code is hardcoded to use: MS_TableConnectionString. Here’s what to check:

• Go to your App Service (B) in the Azure Portal → Configuration → Connection Strings.
• Ensure there’s an entry named MS_TableConnectionString with the exact same value as App Service (A).
• Double-check the connection string’s type (e.g., select SQL Azure if it’s a SQL Database connection). If you pick the wrong type, your code won’t be able to access it correctly.

2. Missing Mobile Service Dependencies #

Migrated App Services often retain hidden dependencies on Mobile Service SDKs or extensions that don’t get copied over when you just move the wwwroot files.

• If you’re using .NET: Verify that all Microsoft.Azure.Mobile.Server related NuGet packages are present in your project’s bin directory. If you copied files manually, you might have missed some DLLs. Re-deploy using your original project (not just wwwroot) to ensure all dependencies are included.
• If you’re using Node.js: Check that your package.json includes all Mobile Service-related packages (like azure-mobile-apps), and that node_modules is properly deployed or restored on App Service (B).

3. Database Firewall & Permissions Issues #

Your database server might be blocking traffic from App Service (B):

• Go to your Azure SQL Database → Networking → Firewall rules.
• Add App Service (B)’s outbound IP addresses (you can find these in App Service (B) → Properties → Outbound IP addresses).
• Alternatively, enable the Allow Azure services and resources to access this server toggle to let App Services connect (use this cautiously if security is a concern).
• Also confirm that the database user account used in your connection string has the necessary read/write permissions for the User table.

4. Runtime Version Mismatch #

New App Services sometimes default to newer runtime versions that aren’t compatible with legacy Mobile Service code:

• For .NET apps: Go to App Service (B) → Configuration → General settings → check that the .NET Framework version matches the one used in App Service (A).
• For Node.js apps: Verify the Node.js version in General settings is the same as your original Mobile Service, and that your code doesn’t rely on deprecated Node APIs.

Can You Deploy Old Mobile Service/Migrated Code to a New App Service? #

Absolutely! Mobile Service code is essentially web app code with specific configuration dependencies. As long as you replicate the connection strings, install the required SDKs, fix firewall/permissions, and match runtime versions, your new App Service (C) will run the old code just like App Service (A).

Debugging Tips #

To get more details than just "Internal Server Error":

• Enable Detailed Error Logging in App Service (B) → Monitoring → App Service logs.
• Use the Log Stream feature to watch real-time error messages as you test the request.service.tables.getTable('User').read() call. This will often reveal the root cause (e.g., a missing DLL, connection string error, or permission issue).

内容的提问来源于stack exchange，提问作者hbear