Localdb là gì

Trong trường hợp các liên kết lại biến mất, tôi sẽ sao chép các giải pháp từ bài viết để truy cập dễ dàng hơn:

Bài 1:

Vấn đề mà chúng tôi đang gặp phải là hồ sơ người dùng cần được tải. Điều đó không khó vì mỗi Nhóm ứng dụng IIS có một tùy chọn được gọi là Tải hồ sơ người dùng có thể tìm thấy trong phần Cài đặt nâng cao . Thật không may, mọi thứ trở nên phức tạp hơn một chút trong Gói Dịch vụ 1 dành cho Windows 7. Như được mô tả trong KB 2547655, việc bật loadUserProfile là không đủ để tải đầy đủ hồ sơ người dùng, chúng tôi cũng cần bật setProfileEnosystem . Điều này yêu cầu chỉnh sửa tệp applicationHost.config thường nằm trong C: \ Windows \ System32 \ inetsrv \ config. Làm theo hướng dẫn từ KB 2547655, chúng ta nên bật cả hai cờ cho Nhóm ứng dụng ASP.NET v4.0, như sau:

Sau khi hoàn tất, chúng tôi khởi động lại Nhóm ứng dụng để đảm bảo các cài đặt mới được áp dụng và chạy lại Ứng dụng web của chúng tôi.

Lưu ý từ phía tôi: Chỉ cần tìm thẻ "applicationPools" trong tệp applicationHost đó và cập nhật hai biến đó thành true, vì vậy nó trông giống như sau:

Vậy là xong, lưu tệp và khởi động lại IIS pool.

Bài 2:

Vấn đề của Phiên bản Riêng tư

Như chúng ta có thể thấy, chúng ta đang gặp phải lỗi sau:

Lần này lỗi khá rõ ràng. LocalDB đã được khởi động và Ứng dụng Web có thể kết nối với nó, nhưng kết nối sau đó đã bị chấm dứt do không đăng nhập được. Tài khoản ApplicationPoolIdentity cho nhóm ứng dụng IIS (trong trường hợp này là IIS APPPOOL \ ASP.NET v4.0 ) không thể đăng nhập vào phiên bản LocalDB vì không tìm thấy cơ sở dữ liệu được chỉ định trong chuỗi kết nối ( OldFashionedDB ). Thật kỳ lạ, vì kết nối từ Visual Studio với cùng một chuỗi kết nối thành công!

Làm thế nào để Visual Studio kết nối tốt với LocalDB, trong khi kết nối từ Ứng dụng web không thành công? Trong cả hai trường hợp, chuỗi kết nối là như sau:

Câu trả lời là có hai phiên bản LocalDB khác nhau ở đây. Không giống như các bản SQL Server Express, đang chạy dưới dạng dịch vụ Windows, các bản LocalDB đang chạy dưới dạng các quy trình của người dùng. Khi những người dùng Windows khác nhau đang kết nối với LocalDB, họ sẽ kết thúc với các quy trình LocalDB khác nhau được bắt đầu cho từng người trong số họ. Khi chúng tôi kết nối với (localdb) \ v11.0từ Visual Studio, một phiên bản LocalDB được khởi động cho chúng tôi và chạy dưới dạng tài khoản Windows của chúng tôi. Nhưng khi Ứng dụng Web, đang chạy trong IIS dưới dạng ApplicationPoolIdentity, đang kết nối với LocalDB, thì một phiên bản LocalDB khác được khởi động cho nó và đang chạy dưới dạng ApplicationPoolIdentity! Trên thực tế, mặc dù cả Visual Studio và Ứng dụng web đang sử dụng cùng một chuỗi kết nối LocalDB, chúng đang kết nối với các phiên bản LocalDB khác nhau. Rõ ràng là cơ sở dữ liệu được tạo từ Visual Studio trên phiên bản LocalDB của chúng tôi sẽ không có sẵn trong phiên bản LocalDB của Ứng dụng Web.

Một tương tự tốt cho điều này là thư mục Tài liệu của tôi trong Windows. Giả sử chúng ta mở Visual Studio và tạo một tệp trong thư mục Tài liệu của tôi . Sau đó, chúng tôi đăng nhập vào cùng một máy với một người dùng khác và chuyển đến thư mục My Documents một lần nữa. Chúng tôi sẽ không tìm thấy tệp ở đó vì Tài liệu của tôi của người dùng thứ hai và Tài liệu của tôi là hai thư mục khác nhau. Tương tự, các phiên bản LocalDB (localdb) \ v11.0 do hai người dùng khác nhau sở hữu là hai quy trình khác nhau với hai bộ cơ sở dữ liệu khác nhau.

Đây cũng là lý do Ứng dụng Web có thể kết nối với LocalDB từ IIS Express. Cũng giống như LocalDB, IIS Express là một quy trình của người dùng. Nó được khởi động bởi Visual Studio và chạy như một tài khoản Windows giống như quá trình Visual Studio. Hai quy trình khác nhau đang chạy trên cùng một tài khoản Windows (Visual Studio và IIS Express, cả hai đều chạy như tài khoản Windows của chúng tôi) kết nối với (localdb) \ v11.0 đang kết nối với cùng một quy trình LocalDB, cũng bắt đầu như cùng một tài khoản Windows.

Phương pháp khả thi

Hiểu được bản chất của vấn đề mang lại nhiều cách tiếp cận để giải quyết nó. Vì các cách tiếp cận khác nhau có sự cân bằng khác nhau, thay vì chỉ định một giải pháp, dưới đây tôi đã trình bày ba cách tiếp cận có vẻ khả thi nhất đối với tôi. Hy vọng của tôi là được nghe ý kiến ​​từ bạn về cách phù hợp nhất với bạn! Đây là danh sách:

Phương pháp 1: Chạy IIS với tư cách là người dùng Windows của chúng tôi
Phương pháp 2: Sử dụng phiên bản dùng chung LocalDB
Phương pháp 3: Sử dụng SQL Server Express đầy đủ

Chúng ta hãy xem xét kỹ hơn từng người trong số họ.

Phương pháp 1: Chạy IIS với tư cách là người dùng Windows của chúng tôi

Nếu các tài khoản người dùng khác nhau là vấn đề, tại sao không thử chạy Ứng dụng web trong tài khoản Windows của chúng tôi? Ứng dụng Web sẽ kết nối với LocalDB giống như Visual Studio và mọi thứ sẽ hoạt động.

Thực hiện thay đổi cấu hình tương đối dễ dàng, chỉ cần khởi động Trình quản lý IIS và tìm Nhóm ứng dụng phù hợp:

Mở màn hình Cài đặt nâng cao (có sẵn trong menu ngữ cảnh):

Nhấp vào nút nhỏ trong thuộc tính Identity để hiển thị màn hình Application Pool Identity :

Khởi động lại Ứng dụng web sẽ xác nhận rằng sự cố đã được giải quyết:

Hạn chế của phương pháp này là gì? Tất nhiên việc chạy Ứng dụng web bằng tài khoản của chúng tôi mang lại những rủi ro bảo mật nhất định. Nếu ai đó chiếm quyền điều khiển Ứng dụng Web của chúng tôi, họ sẽ có thể truy cập vào tất cả các tài nguyên hệ thống mà tài khoản của chúng tôi có thể. Chạy Ứng dụng Web dưới dạng ApplicationPoolIdentity cung cấp khả năng bảo vệ bổ sung vì tài khoản ApplicationPoolIdentity có quyền truy cập rất hạn chế vào tài nguyên hệ thống cục bộ. Vì vậy, tôi không thể khuyến nghị cách tiếp cận này nói chung, nhưng khi sử dụng cẩn thận, nó là một lựa chọn khả thi trong một số trường hợp.

Phương pháp 2: Sử dụng Phiên bản chia sẻ LocalDB

Chúng tôi cũng có thể sử dụng tính năng chia sẻ phiên bản của LocalDB. Nó cho phép chúng tôi chia sẻ phiên bản LocalDB với những người dùng khác trên cùng một máy. Phiên bản được chia sẻ sẽ có thể truy cập được dưới tên công khai.

Cách dễ nhất để chia sẻ một phiên bản là sử dụng tiện ích SqlLocalDB.exe. Chỉ cần bắt đầu lời nhắc dòng lệnh quản trị và nhập lệnh sau:

Nó sẽ chia sẻ phiên bản LocalDB riêng tư v11.0 dưới tên công khai IIS_DB. Tất cả người dùng trên máy sẽ có thể kết nối với phiên bản này, sử dụng (localdb). \ IIS_DB làm địa chỉ máy chủ. Lưu ý. trước tên cá thể, cho biết đây là tên cá thể dùng chung. Chúng ta nên thay thế chuỗi kết nối trong Ứng dụng Web của mình bằng một chuỗi được cập nhật:

Trước khi ứng dụng Web có thể sử dụng cá thể được chia sẻ, chúng ta cần khởi động nó và tạo thông tin đăng nhập cho ApplicationPoolIdentity. Khởi động phiên bản rất dễ dàng, chỉ cần kết nối với nó từ SQL Server Object Explorer sẽ khởi động nó và giữ cho nó tồn tại. Khi chúng ta đang ở trong SQL Server Object Explorer, chúng ta cũng có thể tạo thông tin đăng nhập cho ApplicationPoolIdentity. Chúng tôi có thể sử dụng truy vấn sau:

Tập lệnh này cấp quyền truy cập quản trị đầy đủ vào phiên bản LocalDB của chúng tôi vào tài khoản ApplicationPoolIdentity. Bất cứ khi nào có thể, tôi khuyên bạn nên sử dụng các quyền hạn chế hơn, cấp cơ sở dữ liệu hoặc thậm chí cấp bảng.

Bây giờ chúng ta có thể chạy lại Ứng dụng Web của mình. Lần này nó sẽ hoạt động tốt:

Hạn chế của phương pháp này là gì? Vấn đề chính là, trước khi Ứng dụng Web có thể kết nối với phiên bản được chia sẻ, chúng ta cần đảm bảo phiên bản đó được khởi động. Để điều đó xảy ra, tài khoản Windows sở hữu phiên bản phải kết nối với nó và kết nối phải được giữ ở trạng thái mở, nếu không phiên bản LocalDB sẽ tắt.

Phương pháp 3: Sử dụng SQL Server Express đầy đủ

Vì IIS đầy đủ chạy như một dịch vụ, có thể sử dụng SQL Server Express truyền thống, dựa trên dịch vụ là cách tiếp cận phù hợp? Chúng tôi chỉ có thể cài đặt SQL Server 2012 Express RC0 và tạo cơ sở dữ liệu OldFashionedDB trong đó. Chúng tôi thậm chí có thể sử dụng Công cụ Dữ liệu SQL Server hoàn toàn mới của mình để làm điều đó, vì nó hoạt động với bất kỳ phiên bản và phiên bản SQL Server nào. Chuỗi kết nối của chúng tôi sẽ phải thay đổi thành:

Tất nhiên, cũng giống như trong trường hợp trước, chúng ta cần đảm bảo tài khoản ApplicationPoolIdentity có quyền truy cập vào phiên bản SQL Server Express của chúng tôi. Chúng ta có thể sử dụng cùng một tập lệnh như trước đây:

Sau đó, việc chạy Ứng dụng web của chúng tôi sẽ mang lại bức tranh hạnh phúc một lần nữa:

Hạn chế của phương pháp này là gì? Rõ ràng là chúng ta mất đi những lợi ích khi sử dụng LocalDB. Cài đặt SQL Server Express có thể mất nhiều thời gian hơn LocalDB và có thể có một số thao tác dọn dẹp máy cần thiết để nó thành công. SQL Server Express Setup có thể bị chặn do các sự cố như cơ sở dữ liệu WMI bị hỏng, sổ đăng ký bị ô nhiễm hoặc các thành phần do SQL Server hoặc Visual Studio CTPs và Betas để lại. Và SQL Server Express sẽ tiếp tục chạy trong nền ngay cả khi không cần thiết, giống như các dịch vụ.

Sự lựa chọn khác

Có các cách tiếp cận khác của việc sử dụng LocalDB dưới IIS đầy đủ không được đề cập ở đây. Chúng ta có thể nắm lấy phiên bản LocalDB riêng tư của Ứng dụng Web và giao tiếp với nó thông qua Ứng dụng Web bằng cách thực thi các tập lệnh T-SQL từ mã ASP.NET. Chúng tôi cũng có thể sử dụng tùy chọn AttachDbFileName của chuỗi kết nối ADO.NET và sử dụng tệp cơ sở dữ liệu (.mdf) sẽ được đính kèm vào cả LocalDB của chúng tôi trong quá trình phát triển và LocalDB của Ứng dụng Web để gỡ lỗi. Tôi đã thử cả hai, tôi thấy chúng quá rườm rà để thảo luận thêm.