웹 사이트 프로젝트가 Visual Studio에서 서명 된 어셈블리를 참조 할 수 있습니까?

StackOverflow https://stackoverflow.com/questions/5488864

문제

Visual Studio 2008에서 다음 두 가지 유형의 웹 프로젝트를 알고 있습니다.

  • 웹 사이트 프로젝트
  • 웹 응용 프로그램 프로젝트

    웹 응용 프로그램의 어셈블리가 동일한 키로 서명 된 한 서명 된 어셈블리를 참조 할 수 있습니다. 그러나 어셈블리에 서명 할 위치가 없으므로이 웹 사이트 프로젝트에서는 작동하지 않습니다. 어셈블리가 서버에서 동적으로 컴파일 되므로이 생각입니다.

    어쨌든,이 서명 된 어셈블리로 웹 사이트 프로젝트를 작동시키는 것이 가능합니까? 또는이 웹 사이트 프로젝트를 웹 응용 프로그램 프로젝트로 변환해야합니까?

    편집 :

    다음 상황은이 문제의 설명을 요청할 필요가 있습니다.

    Visual Studio에서 솔루션에서 여러 가지 다른 프로젝트에서 참조되는 클래스 라이브러리가 있습니다. 프로젝트 중 하나는 특정 외부 사용자에게 배포 될 Windows 응용 프로그램입니다. 응용 프로그램이 올바른 어셈블리를 사용하고 다른 사람들이 어셈블리를 사용하는 것을 방지하고 다른 어셈블리를 인식하면 모든 어셈블리가 서명되었으며 라이브러리의 모든 클래스가 선언되었습니다. 친구 (내부)로.

    웹 사이트 프로젝트는 내 어셈블리에 서명 할 수있는 방법이 없으며 라이브러리에서 아무 것도 사용하려고 시도 할 때 다음 메시지를받는 것처럼 보입니다. 예상되는 것입니다.

    다음 속성은 내 클래스 라이브러리 프로젝트의 AssemblyInfo.vb 파일 안에 있습니다. 

    <Assembly: InternalsVisibleTo("OtherProject1, PublicKey=AAA...")>
<Assembly: InternalsVisibleTo("OtherProject2, PublicKey=AAA...")>
...
    .

    내 결론 :

    이 작업을 수행하는 가장 깨끗한 방법은 웹 사이트를 웹 응용 프로그램으로 변환하는 것입니다. 그러나 우리 사이트가 이미 꽤 살고 다른 토론에서 지적한 것처럼 꽤 살아남 이므로이 사이트가 필요합니다. 고통스러워. 앞으로, 나는 처음에는 웹 응용 프로그램을 만드는 것이 더 나은 아이디어와 미래의 개발을 위해 훨씬 더 유연 할 수 있다고 생각합니다.

도움이 되었습니까?

해결책

There's no requirement for the two projects to be signed with the same key - after all the framework assemblies are all signed with MS's key, which you don't have access to yet you can happily reference them from both Web Site and Web Application projects.

There's nothing at all stopping you referencing a signed assembly from a Website project - what errors are you seeing?

Edit to add

In light of your updated information, yes, I think you'll have to either:

  1. Convert the web site to a web application - as you rightly point out, there's no way to sign the site, and indeed, there's no real control over the libraries that ASP.NET will generate for the site.
  2. Compile two versions of the class library, one signed, the other not. You could probably use conditional compilation to achieve this.

Edit to add

I think the conditional compilation will probably end up getting messy quickly, but in brief it would work like this:

  • Open the Project Properties for the class library, and go to the Build tab.
  • Switch the "Configuration" dropdown to "All Configurations"
  • In the "Conditional compilation symbols" box, add a new symbol, such as "INTERNAL".

Go to the class libraries that you want to make public, and modify them to something like:

#if INTERNAL
  internal class MyClass
#else
  public class MyClass
#endif
  {
    [...]
  }

Then, when you need to produce the Public version of the library, remove the "INTERNAL" symbol from the properties and rebuild - you could make this easier by creating a new set of Debug and Release configurations that have this symbol defined, and switch between them using the Solution Configuration dropdown.

Potential issues:

  1. It might not be easy to tell whether you've got the symbol defined or not - I don't know what the behaviour is in vanilla VS, however with ReSharper installed it will grey out the parts of the code that won't be compiled under the current set of symbols, and flags the class as inaccessible as you type.
  2. You'll want to leave your properties and methods as public so that when you don't build it as "INTERNAL" you can access the them, but this will look a bit odd (although doesn't produce any warnings so clearly is legal).

다른 팁

Now that I have a clearer picture of the issue I see that my original answer does not apply well. What I have done before in a similar situation was to use source control to branch the code files for the "Friend" classes into the consuming project so that they compile as part of the consuming assembly.

In my case I was trying to reuse some code in different server control projects without putting it into a separate dll, but I suspect it would also work well for your website scenario. It would mean your web site has no need to reference the signed DLL because the classes are compiled as part of the site and therefore all of the internal declarations should be available to it.

I don't know if this would be an option for you or not, largely depends on what source control tool you use, how you have your code repository set up, and how comfortable you are with the branching and merging concept.

Public members of a signed assembly should be available to any other project which has access to the DLL. I have created several signed assemblies and distributed them to other members of my team, we have used them in a mix of websites, web projects and console apps. The only place we ran into a conflict was when we tried to use an assembly that referenced HttpContext.Current in a console app. Even that worked if we avoided the methods which utilized this reference.

The only case in which signing/keys should be an issue is if you are trying to make them "Friends", meaning that they can see eachothers internal types and methods. The rules about friends and signing are documented here: http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top