Câu hỏi Các chỉ thị 'sử dụng' có nên ở bên trong hay bên ngoài vùng tên không?


tôi đã chạy StyleCop trên một số mã C # và nó tiếp tục báo cáo rằng using các chỉ thị phải nằm trong không gian tên.

Có lý do kỹ thuật nào để đặt using chỉ thị bên trong thay vì bên ngoài không gian tên?


1741
2017-09-24 03:49


gốc


Đôi khi nó làm cho sự khác biệt nơi bạn đặt sử dụng: stackoverflow.com/questions/292535/linq-to-sql-designer-bug - gius
Chỉ để tham khảo, có những hàm ý vượt ra ngoài chỉ là câu hỏi của nhiều lớp cho mỗi tệp, vì vậy nếu bạn mới làm quen với câu hỏi này, hãy tiếp tục đọc. - Charlie
@ user-12506 - điều này không hoạt động tốt trong một nhóm phát triển trung bình đến lớn, nơi cần một số mức độ nhất quán mã. Và như đã nói ở trên, nếu bạn không hiểu các bố cục khác nhau, bạn có thể thấy các trường hợp cạnh không hoạt động như bạn mong đợi. - benPearce
Thuật ngữ: Đó không phải là using  các câu lệnh; họ đang using  chỉ thị. A using tuyên bố, mặt khác, là một cấu trúc ngôn ngữ xảy ra cùng với các câu lệnh khác bên trong một thân phương thức, vv Ví dụ, using (var e = s.GetEnumerator()) { /* ... */ } là một tuyên bố đó là lỏng lẻo giống như var e = s.GetEnumerator(); try { /* ... */ } finally { if (e != null) { e.Dispose(); } }. - Jeppe Stig Nielsen
Nếu điều này không được đề cập bởi bất kỳ ai, thực sự Microsoft cũng khuyên bạn nên đặt using báo cáo bên trong namespace tờ khai, trong hướng dẫn mã hóa nội bộ - user1451111


Các câu trả lời:


Thực sự có một sự khác biệt (tinh tế) giữa hai người. Hãy tưởng tượng bạn có đoạn mã sau trong File1.cs:

// File1.cs
using System;
namespace Outer.Inner
{
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

Bây giờ hãy tưởng tượng rằng ai đó thêm tập tin khác (File2.cs) vào dự án trông như thế này:

// File2.cs
namespace Outer
{
    class Math
    {
    }
}

Tìm kiếm trình biên dịch Outer trước khi nhìn vào những using chỉ thị bên ngoài vùng tên, vì vậy nó tìm thấy Outer.Math thay vì System.Math. Thật không may (hoặc có lẽ may mắn?), Outer.Math không có PI thành viên, vì vậy File1 hiện đã bị hỏng.

Điều này thay đổi nếu bạn đặt using bên trong khai báo không gian tên của bạn, như sau:

// File1b.cs
namespace Outer.Inner
{
    using System;
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

Bây giờ tìm kiếm trình biên dịch System trước khi tìm kiếm Outer, tìm System.Mathvà tất cả đều tốt.

Một số người cho rằng Math có thể là một tên xấu cho một lớp do người dùng định nghĩa, vì đã có một System; điểm ở đây chỉ là ở đó  sự khác biệt và ảnh hưởng đến khả năng bảo trì mã của bạn.

Nó cũng thú vị để lưu ý những gì sẽ xảy ra nếu Foo nằm trong không gian tên Outer, thay vì Outer.Inner. Trong trường hợp đó, thêm Outer.Math trong File2 phá vỡ File1 bất kể nơi using đi. Điều này ngụ ý rằng trình biên dịch tìm kiếm không gian tên bao quanh bên trong trước khi nó nhìn vào bất kỳ using chỉ thị.


1844
2017-09-30 02:33



Đây là một lý do tốt hơn để đặt câu lệnh cục bộ hơn so với đối số nhiều tên-trong-một-tệp của Mark. Đặc biệt là việc biên dịch có thể và sẽ khiếu nại về xung đột đặt tên (xem tài liệu StyleCop cho quy tắc này (ví dụ như được đăng bởi Jared)). - David Schmitt
Câu trả lời được chấp nhận là tốt, nhưng với tôi nó có vẻ như là một lý do chính đáng để đưa các mệnh đề sử dụng ở ngoài không gian tên. Nếu tôi đang ở trong không gian tên Outer.Inner tôi mong đợi nó sẽ sử dụng lớp Math từ Outer.Inner chứ không phải System.Math. - Frank Wallis
Tôi đồng ý với điều này là tốt. Câu trả lời được chấp nhận là chính xác ở chỗ nó mô tả kỹ thuật sự khác biệt. Tuy nhiên, một hoặc lớp khác sẽ cần một chú dẫn rõ ràng. Tôi sẽ rất nhiều ratehr có "Toán" giải quyết cho lớp học địa phương của riêng tôi, và "System.Math" tham khảo các lớp bên ngoài - ngay cả khi System.Math đã được sử dụng như là "Toán" trước khi Outer.Math tồn tại. Có, đó là công việc nhiều hơn để sửa chữa tuy nhiên nhiều tài liệu tham khảo từ trước, nhưng đó cũng có thể là một gợi ý rằng có lẽ Outer.Math nên có một tên khác nhau! - mbmcavoy
Câu trả lời tuyệt vời, nhưng có vẻ như với tôi rằng tôi chỉ muốn đặt các khung công tác không sử dụng khung nội bộ, và giữ cho khung công tác sử dụng các câu lệnh toàn cục. Bất cứ ai cũng có giải thích thêm tại sao tôi hoàn toàn nên thay đổi sở thích của mình? Ngoài ra nơi đã làm điều này đến từ, các mẫu trong VS2008 đặt sử dụng bên ngoài không gian tên? - Thymine
Tôi nghĩ rằng đây là một quy ước đặt tên xấu hơn là thay đổi địa điểm sử dụng của bạn. Không nên có một lớp được gọi là Toán trong giải pháp của bạn - jDeveloper


Chủ đề này đã có một số câu trả lời tuyệt vời, nhưng tôi cảm thấy tôi có thể mang lại một chút chi tiết hơn với câu trả lời bổ sung này.

Trước tiên, hãy nhớ rằng một khai báo không gian tên với các dấu chấm, như:

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    ...
}

hoàn toàn tương đương với:

namespace MyCorp
{
    namespace TheProduct
    {
        namespace SomeModule
        {
            namespace Utilities
            {
                ...
            }
        }
    }
}

Nếu bạn muốn, bạn có thể đặt using chỉ thị trên tất cả các cấp độ này. (Tất nhiên, chúng tôi muốn có usingchỉ ở một nơi, nhưng nó sẽ là hợp pháp theo ngôn ngữ.)

Quy tắc để giải quyết loại được ngụ ý, có thể được khai báo lỏng lẻo như sau: Đầu tiên tìm kiếm "phạm vi" bên trong nhất cho một trận đấu, nếu không có gì được tìm thấy ở đó, đi ra một cấp độ cho phạm vi tiếp theo và tìm kiếm ở đó, v.v., cho đến khi một kết hợp được tìm thấy. Nếu ở một số cấp độ nhiều hơn một kết hợp được tìm thấy, nếu một trong các loại là từ lắp ráp hiện tại, chọn một trong đó và đưa ra một cảnh báo trình biên dịch. Nếu không, hãy từ bỏ (lỗi thời gian biên dịch).

Bây giờ, chúng ta hãy rõ ràng về những gì điều này có nghĩa trong một ví dụ cụ thể với hai công ước lớn.

(1) Với việc sử dụng bên ngoài:

using System;
using System.Collections.Generic;
using System.Linq;
//using MyCorp.TheProduct;  <-- uncommenting this would change nothing
using MyCorp.TheProduct.OtherModule;
using MyCorp.TheProduct.OtherModule.Integration;
using ThirdParty;

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    class C
    {
        Ambiguous a;
    }
}

Trong trường hợp trên, để tìm ra loại nào Ambiguous là, tìm kiếm đi theo thứ tự này:

  1. Các loại lồng nhau bên trong C (bao gồm các loại lồng nhau được kế thừa)
  2. Các loại trong không gian tên hiện tại MyCorp.TheProduct.SomeModule.Utilities
  3. Các loại trong không gian tên MyCorp.TheProduct.SomeModule
  4. Các loại trong MyCorp.TheProduct
  5. Các loại trong MyCorp
  6. Các loại trong vô giá trị không gian tên (không gian tên chung)
  7. Các loại trong System, System.Collections.Generic, System.Linq, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.IntegrationThirdParty

Công ước khác:

(2) Với việc sử dụng bên trong:

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using MyCorp.TheProduct;                           // MyCorp can be left out; this using is NOT redundant
    using MyCorp.TheProduct.OtherModule;               // MyCorp.TheProduct can be left out
    using MyCorp.TheProduct.OtherModule.Integration;   // MyCorp.TheProduct can be left out
    using ThirdParty;

    class C
    {
        Ambiguous a;
    }
}

Bây giờ, tìm kiếm loại Ambiguous đi theo thứ tự sau:

  1. Các loại lồng nhau bên trong C (bao gồm các loại lồng nhau được kế thừa)
  2. Các loại trong không gian tên hiện tại MyCorp.TheProduct.SomeModule.Utilities
  3. Các loại trong System, System.Collections.Generic, System.Linq, MyCorp.TheProduct, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.IntegrationThirdParty
  4. Các loại trong không gian tên MyCorp.TheProduct.SomeModule
  5. Các loại trong MyCorp
  6. Các loại trong vô giá trị không gian tên (không gian tên chung)

(Lưu ý rằng MyCorp.TheProduct là một phần của "3." và do đó không cần thiết giữa "4." và "5.".)

Kết luận

Không có vấn đề nếu bạn đặt các sử dụng bên trong hoặc bên ngoài khai báo không gian tên, luôn có khả năng một người nào đó sau đó thêm một kiểu mới với tên giống hệt với một trong các không gian tên có mức độ ưu tiên cao hơn.

Ngoài ra, nếu một không gian tên lồng nhau có cùng tên như một loại, nó có thể gây ra vấn đề.

Luôn luôn nguy hiểm khi di chuyển việc sử dụng từ vị trí này sang vị trí khác vì thay đổi phân cấp tìm kiếm và một loại khác có thể được tìm thấy. Do đó, hãy chọn một quy ước và tuân theo quy ước đó để bạn không phải di chuyển các bài viết.

Các mẫu của Visual Studio, theo mặc định, đặt các giá trị ở ngoài của không gian tên (ví dụ nếu bạn tạo VS tạo một lớp mới trong một tệp mới).

Một (nhỏ) lợi thế của việc sử dụng ở ngoài là sau đó bạn có thể sử dụng các chỉ thị sử dụng cho một thuộc tính toàn cầu, ví dụ [assembly: ComVisible(false)] thay vì [assembly: System.Runtime.InteropServices.ComVisible(false)].


346
2018-04-18 21:00



cảm ơn, đây là một lời giải thích tốt hơn nhiều so với câu trả lời được chấp nhận. - thor_hayek
Đây là giải thích tốt nhất, bởi vì nó làm nổi bật thực tế là vị trí của các câu lệnh 'sử dụng' là một quyết định có chủ ý từ nhà phát triển. Trong mọi trường hợp không nên ai đó bất cẩn thay đổi vị trí của các câu lệnh 'sử dụng' mà không hiểu các hàm ý. Do đó quy tắc StyleCop chỉ là câm. - ZunTzu


Đặt nó vào bên trong không gian tên làm cho các khai báo cục bộ đến không gian tên đó cho tệp (trong trường hợp bạn có nhiều không gian tên trong tệp), nhưng nếu bạn chỉ có một không gian tên cho mỗi tệp thì nó không tạo ra nhiều khác biệt cho dù chúng đi ra ngoài hay bên trong không gian tên.

using ThisNamespace.IsImported.InAllNamespaces.Here;

namespace Namespace1
{ 
   using ThisNamespace.IsImported.InNamespace1.AndNamespace2;

   namespace Namespace2
   { 
      using ThisNamespace.IsImported.InJustNamespace2;
   }       
}

namespace Namespace3
{ 
   using ThisNamespace.IsImported.InJustNamespace3;
}

178
2017-09-24 03:52



các không gian tên cung cấp sự tách biệt hợp lý, không phải là một sự phân tách vật lý (tập tin). - Jowen
Không hoàn toàn đúng là không có sự khác biệt; using chỉ thị trong namespace các khối có thể tham chiếu đến các không gian tên tương đối dựa trên bao quanh namespace khối. - O. R. Mapper
Vâng, tôi biết. chúng tôi đã thiết lập rằng trong câu trả lời được chấp nhận của câu hỏi này năm năm trước. - Mark Cidade


Theo Hanselman - Sử dụng Chỉ thị và Lắp ráp Đang tải ... và các bài viết khác như vậy về mặt kỹ thuật không có sự khác biệt về mặt kỹ thuật.

Sở thích của tôi là đặt chúng bên ngoài không gian tên.


56
2017-09-24 03:53



@ Chris M: uh ... liên kết được đăng trong câu trả lời cho biết có Không lợi ích của việc so sánh, thực sự cho thấy một ví dụ làm sai lệch yêu cầu được đưa ra trong liên kết bạn đã đăng ... - johnny
Aye tôi đã không đọc đầy đủ các chủ đề nhưng mua trong khi MVPs nói rằng nó là đúng. Một anh chàng bác bỏ nó, giải thích nó và cho thấy mã của anh ta tiếp tục xuống ... "IL mà trình biên dịch C # tạo ra là giống nhau trong cả hai trường hợp. Trong thực tế trình biên dịch C # tạo ra chính xác không có gì tương ứng với từng chỉ thị bằng cách sử dụng. C # ism, và chúng không có ý nghĩa với chính .NET. (Không đúng với việc sử dụng câu lệnh nhưng đó là một cái gì đó khá khác.) " groups.google.com/group/wpf-disciples/msg/781738deb0a15c46 - Chris McKee
Vui lòng bao gồm bản tóm tắt liên kết. Khi nào liên kết bị hỏng (vì nó sẽ xảy ra, cho đủ thời gian), đột nhiên một câu trả lời với 32 upvotes chỉ có giá trị My style is to put them outside the namespaces. - hầu như không có câu trả lời nào cả. - ANeves
Yêu cầu bồi thường ở đây đơn giản là sai ... có sự khác biệt về mặt kỹ thuật và trích dẫn của riêng bạn nói như vậy ... trên thực tế, đó là tất cả những gì về nó. Vui lòng xóa câu trả lời sai lầm này ... có những câu trả lời chính xác hơn và chính xác hơn nhiều. - Jim Balter


Theo tài liệu StyleCop:

SA1200: Sử dụngDirectivesMustBePlacedWithinNamespace

Nguyên nhân Một C # sử dụng chỉ thị được đặt bên ngoài một phần tử không gian tên.

Mô tả quy tắc Vi phạm quy tắc này xảy ra khi chỉ thị sử dụng hoặc chỉ thị sử dụng bí danh được đặt bên ngoài phần tử không gian tên, trừ khi tệp không chứa bất kỳ phần tử không gian tên nào.

Ví dụ: mã sau sẽ dẫn đến hai vi phạm quy tắc này.

using System;
using Guid = System.Guid;

namespace Microsoft.Sample
{
    public class Program
    {
    }
}

Tuy nhiên, mã sau sẽ không dẫn đến bất kỳ vi phạm nào về quy tắc này:

namespace Microsoft.Sample
{
    using System;
    using Guid = System.Guid;

    public class Program
    {
    }
}

Mã này sẽ biên dịch gọn gàng, không có bất kỳ lỗi trình biên dịch nào. Tuy nhiên, không rõ phiên bản nào của loại Guid đang được phân bổ. Nếu chỉ thị sử dụng được di chuyển bên trong vùng tên, như được hiển thị bên dưới, một lỗi trình biên dịch sẽ xảy ra:

namespace Microsoft.Sample
{
    using Guid = System.Guid;
    public class Guid
    {
        public Guid(string s)
        {
        }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            Guid g = new Guid("hello");
        }
    }
}

Mã lỗi trên lỗi trình biên dịch sau đây, được tìm thấy trên dòng có chứa Guid g = new Guid("hello"); 

CS0576: Không gian tên 'Microsoft.Sample' chứa một định nghĩa mâu thuẫn với bí danh 'Guid'

Mã này tạo ra một bí danh cho kiểu System.Guid có tên Guid, và cũng tạo ra kiểu riêng của nó có tên là Guid với một giao diện hàm dựng phù hợp. Sau đó, mã tạo ra một thể hiện của kiểu Guid. Để tạo ra thể hiện này, trình biên dịch phải chọn giữa hai định nghĩa khác nhau của Guid. Khi chỉ thị sử dụng bí danh được đặt bên ngoài phần tử không gian tên, trình biên dịch sẽ chọn định nghĩa cục bộ của Guid được định nghĩa trong không gian tên cục bộ và hoàn toàn bỏ qua chỉ thị sử dụng bí danh được định nghĩa bên ngoài vùng tên. Điều này, thật không may, không rõ ràng khi đọc mã.

Tuy nhiên, khi chỉ thị sử dụng-alias được định vị trong không gian tên, trình biên dịch phải chọn giữa hai loại Guid khác nhau, xung đột được xác định trong cùng một không gian tên. Cả hai loại này đều cung cấp một hàm tạo phù hợp. Trình biên dịch không thể đưa ra quyết định, vì vậy nó sẽ gắn cờ lỗi trình biên dịch.

Việc đặt chỉ thị sử dụng bí danh bên ngoài vùng tên là một thực hành không tốt vì nó có thể dẫn đến sự nhầm lẫn trong các tình huống như thế này, ở đây không rõ phiên bản nào thực sự đang được sử dụng. Điều này có khả năng dẫn đến một lỗi có thể khó chẩn đoán.

Đặt các chỉ thị sử dụng-bí danh trong phần tử không gian tên loại bỏ điều này như là một nguồn của các lỗi.

  1. Nhiều không gian tên miền

Việc đặt nhiều phần tử không gian tên trong một tệp thường là một ý tưởng tồi, nhưng nếu và khi điều này được thực hiện, bạn nên đặt tất cả các chỉ thị bằng cách sử dụng các chỉ thị trong mỗi phần tử không gian tên chứ không phải toàn cầu ở đầu tệp. Điều này sẽ phạm vi chặt chẽ các không gian tên, và cũng sẽ giúp tránh các loại hành vi được mô tả ở trên.

Điều quan trọng cần lưu ý là khi mã được viết bằng cách sử dụng các chỉ thị được đặt bên ngoài vùng tên, cần lưu ý khi di chuyển các chỉ thị này trong không gian tên, để đảm bảo rằng điều này không làm thay đổi ngữ nghĩa của mã. Như đã giải thích ở trên, việc đặt các chỉ thị sử dụng bí danh trong phần tử không gian tên cho phép trình biên dịch lựa chọn giữa các kiểu xung đột theo các cách sẽ không xảy ra khi các chỉ thị được đặt bên ngoài vùng tên.

Cách khắc phục vi phạm Để khắc phục vi phạm quy tắc này, hãy di chuyển tất cả bằng cách sử dụng chỉ thị và chỉ thị sử dụng bí danh trong phần tử không gian tên.


45
2017-09-14 15:17



@ Jared - như tôi đã lưu ý trong câu trả lời của tôi, giải pháp thích hợp của tôi / giải pháp là chỉ bao giờ có một lớp cho mỗi tệp. Tôi nghĩ rằng đây là một quy ước khá phổ biến. - benPearce
Thật vậy, nó cũng là một quy tắc StyleCop! SA1402: Tài liệu C # chỉ có thể chứa một lớp duy nhất ở cấp cơ sở trừ khi tất cả các lớp là một phần và cùng loại. Hiển thị một quy tắc bằng cách phá vỡ một quy tắc khác chỉ với những giọt nước sốt sai. - Task
Được bình chọn là câu trả lời đầu tiên để che giấu nó từ phối cảnh StyleCop. Cá nhân tôi thích cảm giác hình ảnh của usingbên ngoài không gian tên. Bên trong usings trông xấu xí với tôi. :) - nawfal
Cuối cùng là một câu trả lời tốt cho câu hỏi. Và nhận xét của benPearce là không liên quan ... điều này không liên quan gì đến số lượng lớp trong tệp. - Jim Balter


Có vấn đề với việc sử dụng các câu lệnh bên trong không gian tên khi bạn muốn sử dụng bí danh. Bí danh không được hưởng lợi từ phiên bản cũ hơn using báo cáo và phải đủ điều kiện.

Xem xét:

namespace MyNamespace
{
    using System;
    using MyAlias = System.DateTime;

    class MyClass
    {
    }
}

đấu với:

using System;

namespace MyNamespace
{
    using MyAlias = DateTime;

    class MyClass
    {
    }
}

Điều này có thể được phát âm đặc biệt nếu bạn có một bí danh dài dòng như sau (đó là cách tôi đã tìm ra vấn đề):

using MyAlias = Tuple<Expression<Func<DateTime, object>>, Expression<Func<TimeSpan, object>>>;

Với using các câu lệnh bên trong không gian tên, nó đột nhiên trở thành:

using MyAlias = System.Tuple<System.Linq.Expressions.Expression<System.Func<System.DateTime, object>>, System.Linq.Expressions.Expression<System.Func<System.TimeSpan, object>>>;

Không đẹp.


29
2017-10-10 18:47



Của bạn class cần một tên (số nhận dạng). Bạn không thể có một using chỉ thị bên trong một lớp như bạn chỉ ra. Nó phải ở trên một mức không gian tên, ví dụ bên ngoài ngoài cùng namespace, hoặc chỉ bên trong trong cùng namespace (nhưng không phải bên trong một lớp / giao diện / etc.). - Jeppe Stig Nielsen
@JeppeStigNielsen Cảm ơn. Tôi đã thất lạc using chỉ thị nhầm lẫn. Tôi đã chỉnh sửa nó theo cách tôi dự định. Cảm ơn bạn đã chỉ ra. Tuy nhiên, lý do vẫn là như nhau. - Neo


Như Jeppe Stig Nielsen nói, chủ đề này đã có câu trả lời tuyệt vời, nhưng tôi nghĩ rằng sự tinh tế khá rõ ràng này đáng được nhắc tới.

using chỉ thị được chỉ định bên trong không gian tên có thể tạo mã ngắn hơn vì chúng không cần phải đủ điều kiện như khi chúng được chỉ định ở bên ngoài.

Ví dụ sau đây hoạt động vì các loại Foo và Bar đều nằm trong cùng một không gian tên chung, Outer.

Giả sử tệp mã Foo.cs:

namespace Outer.Inner
{
    class Foo { }
}

Bar.cs:

namespace Outer
{
    using Outer.Inner;

    class Bar
    {
        public Foo foo;
    }
}

Điều đó có thể bỏ qua không gian tên bên ngoài trong using chỉ thị, viết tắt:

namespace Outer
{
    using Inner;

    class Bar
    {
        public Foo foo;
    }
}

2
2017-09-17 10:32



Đúng là bạn "có thể bỏ qua không gian tên bên ngoài", nhưng nó không có nghĩa là bạn nên. Đối với tôi, đây là một lý lẽ khác về lý do tại sao sử dụng các chỉ thị (ngoài các bí danh như trong câu trả lời của @ Neo) nên đi ra ngoài vùng tên, để buộc các tên không gian tên đầy đủ. - Keith Robertson


Các lý do kỹ thuật được thảo luận trong các câu trả lời và tôi nghĩ rằng nó đi kèm với các sở thích cá nhân cuối cùng vì sự khác biệt không phải là to và có sự cân bằng cho cả hai. Mẫu mặc định của Visual Studio để tạo .cstập tin sử dụng using chỉ thị bên ngoài không gian tên, ví dụ:

Người ta có thể điều chỉnh stylecop để kiểm tra using chỉ thị bên ngoài không gian tên thông qua việc thêm stylecop.json tập tin trong thư mục gốc của tập tin dự án với những điều sau đây:

{
  "$schema": "https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json",
    "orderingRules": {
      "usingDirectivesPlacement": "outsideNamespace"
    }
  }
}

Bạn có thể tạo tệp cấu hình này ở cấp độ giải pháp và thêm nó vào dự án của bạn dưới dạng 'Tệp liên kết hiện có' để chia sẻ cấu hình trên tất cả các dự án của bạn.


0
2018-06-03 12:38