Chúng tôi có (thuần khiết C++) .DLL được xây dựng bởi VS. Là khách hàng, chúng tôi có một số ứng dụng C++ gốc và một .Net-Wrapper xung quanh DLL này được viết bằng C++/CLI. Cuối cùng có một số ứng dụng máy khách cho .Net-Wrapper được viết bằng C#.Làm thế nào để liên kết một .DLL tĩnh?
Vấn đề của tôi là tệp native.dll phải được phân phối theo cách khác với công việc của thế giới .Net và VS không theo dõi tệp DLL đó. Vì vậy, để cho tất cả các ứng dụng C# hoạt động chính xác, tôi phải sao chép nó vào mỗi thư mục thực thi hoặc đặt nó ở đâu đó trong% PATH% (mà tôi sẽ tránh trên máy tính của nhà phát triển vì chúng có thể muốn bắt đầu các ứng dụng khác nhau với các phiên bản DLL khác nhau) . Sự cố lớn hơn xảy ra nếu có UserControls tham chiếu đến Wrapper-DLL: Bạn phải sao chép tệp DLL vào thư mục của VS hoặc lại thành% PATH%. Nhưng trường hợp xấu nhất xảy ra với công cụ Dịch của chúng tôi. Công cụ này theo dõi .Net-Assemblies và gói chúng vào các gói Translator, có thể gửi tới một dịch giả bên ngoài. Theo tôi biết không có cách nào để đưa bản địa .DLL vào gói đó!
Vì vậy, tôi có kế hoạch liên kết DLL gốc tĩnh vào .Net-Wrapper sẽ giải quyết được sự cố của tôi. Nhưng đối với các ứng dụng Native của chúng tôi, DLL gốc này vẫn phải là một DLL.
Vì vậy, tôi có hai lựa chọn:
- Làm cho hai dự án đó (một mà tạo ra một thư viện tĩnh; và một trong đó tạo ra một năng động => tôi cố gắng tránh điều này)
- Tìm một giải pháp để liên kết DLL tĩnh
- Tìm một cách để cho VS tạo ra hai kết quả đầu ra từ một dự án
Tôi có thể hơi điên một chút ở đây, nhưng tôi không hiểu tại sao các ứng dụng bản địa của bạn không thể sử dụng dll gốc, và các ứng dụng .net của bạn sử dụng dll C++/cli-wrap. – Niklas
Cả hai đều có thể. Nhưng Wrapper-DLL tham chiếu đến DLL gốc và vì vậy các ứng dụng C# của tôi cần cả hai. Đó là OK cho wrapper nhưng là đau trong ass cho DLL bản địa. – mmmmmmmm
Tại sao không chỉ xây dựng một lib cho dll? Bạn nói rằng bạn xây dựng dll bằng cách sử dụng VS, không? –