网站项目是否可能参考Visual Studio中的签名组件？

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

题

我知道Visual Studio 2008中的以下两种不同类型的Web项目：

  • 网站项目
  • Web应用程序项目

    只要Web应用程序的组装也使用相同的键签名，Web应用程序项目就可以引用符号组件。但是，这不适用于网站项目，因为没有签署程序集的地方。我认为这是因为组装是在服务器上动态编译的吗？

    无论如何，是否有可能让网站项目与此签名的集会一起使用？或者我必须将此网站项目转换为Web应用程序项目？

    编辑：

    以下情况已要求我在此问题上要求澄清：

    我有一个类库，它是由我在Visual Studio的解决方案中的其他几个项目引用的库。其中一个项目是将部署到特定外部用户的Windows应用程序。为了确保应用程序正在使用正确的组件，并且还可以防止他人使用组件（我知道关于其效率的限制），已签名所有装配块，并且声明了库中的所有类别作为朋友（内部）。

    网站项目似乎没有办法让我签署它的装配，并且在尝试使用库中的任何内容时，我收到以下消息：“在此上下文中没有评估类，因为它是”朋友“” ，预期。

    以下属性在我的类库项目中的AssemberyInfo.vb文件中： 

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

    我的结论：

    看起来像最干净的方式是要将网站转换为Web应用程序，但这需要一点时间以来，自从我们的网站已经漂亮地完成，就像其他讨论中所指出的那样，可以相当痛苦做。前进，我认为首先创建一个Web应用程序可能是一个更好的主意，更灵活地为未来的发展。

有帮助吗？

解决方案

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