我正在使用VS 2013将Web角色部署到Azure。我在Contents
文件中添加了.csdef
元素,以部署Azure部署包中未包含的额外文件,如下所示: / p>
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="..." xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
<WebRole name="..." vmsize="Small">
<!-- snip -->
<Contents>
<Content destination="bin/">
<SourceDirectory path="C:\...\bin"/>
</Content>
</Contents>
</WebRole>
</ServiceDefinition>
部署软件包后,我可以看到额外的文件放在实例approot
驱动器的F:
文件夹中。但是,这些文件永远不会部署到sitesroot\0
文件夹,Web角色似乎从该文件夹运行。因为这些额外的文件是要动态加载的程序集,所以我希望它们与应用程序的其他程序集一起使用。
这种行为是故意还是我做错了什么?在线似乎没有太多关于此的信息。
答案 0 :(得分:1)
我最终在最后使用了Content元素,但是使用了不同的目标路径,指向sitesroot文件夹。这有点像黑客攻击,但至少它没有深入到MSBuild或部署的手动打包中。
<ServiceDefinition name="..." xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
<WebRole name="..." vmsize="Small">
<!-- snip -->
<Contents>
<Content destination="..\sitesroot\0\bin">
<SourceDirectory path="C:\...\bin" />
</Content>
</Contents>
</WebRole>
</ServiceDefinition>
答案 1 :(得分:0)
行为是as per the documentation,表明部署的位置是相对于角色的APPROOT(您看到的行为)。
如果您希望将它们部署到您网站的bin文件夹中,则需要将它们打包为Visual Studio解决方案的一部分。
答案 2 :(得分:0)
您可以将DLL添加到项目的根目录(Add - &gt; Existing Item)。如果您使用该DLL并将Build Action
设置更改为Content
并将Copy to Output Directory
设置为Copy Always
,那么我认为这将确保DLL最终位于您的{ {1}}文件夹,或等同于
我过去做过的一个例子: 解决方案中的两个项目名为:
BIN
(班级图书馆)DependenciesProject
(MVC App)我需要包含一些需要捆绑到编译包中的特定DLL,但是将使用的特定DLL将根据我编译的目标(x64 vs x86)进行更改。我们选择使用的解决方案是让WebProject
执行上面描述的操作,然后修改DependenciesProject
文件以根据编译时指定的目标更改这些本机DLL的路径-time(我们已停用.csproj
)。
因此Any CPU
在根目录中有这些DLL(DependenciesProject
对我们的Nuget .csproj
文件夹中存在的DLL的动态路径进行了一些调整)和DLL中的DLL解决方案资源管理器将packages
设置为Build Action
,将Content
设置为Copy to Output Directory
。这意味着无论何时编译Copy Always
文件,它都会将其他DLL移动到与.DLL文件相同的输出文件夹中。
现在DependenciesProject.dll
项目将有WebProject
的项目参考。这意味着每次我尝试编译DependenciesProject
时,它将首先编译WebProject
,然后将其输出文件夹复制到DependenciesProject
的输出文件夹中。
最终结果:每次我需要时,我的网络应用程序都存在WebProject
以及DependenciesProject.dll
。
这有帮助吗?