这个问题是为什么一些pipe理员不喜欢从服务器共享执行exes？ 我开发了一个实用工具，使Access开发人员的生活变得更加简单。 由于上述链接的反馈，我将提供一个选项，使得IT部门可以在客户端系统上安装MSI文件。
我想到的一个select是让开发人员能够将exe从服务器共享复制到用户Application Data文件夹。 另一个可能性是用户可以执行的exe / msi，这也将exe放在用户Application Data文件夹中。
注释？
我注意到Google已经在App Data文件夹中安装了Chrome，Google Talk和一大堆更新前缀和dll。 以及其他一些scheme。 不是我想用这个借口。
添加
我从开发者那里得到了一些评论，说他们只需要使用我的一小部分系统的实用程序。 IT部门将花费数月和数月的时间评估事物，不想处理这些程序，除非它们是公司成像系统的一部分。 另外，开发人员可能希望比IT部门更快地处理实用程序的更新。
那么，在networking主文件夹（相当常见）的情况下，您仍然有从networking共享开始的所有问题，因为事实上就是这样。
老实说，我不明白。 有一些方法应该安装在Windows平台上运行。 你为什么不遵循这些经过validation的方法呢？ 真的，我遇到的很多Windows应用程序的问题都可以追溯到程序员，他们不知道Windows程序如何安装和运行，或者认为是复杂的，并采取了一些捷径或类似的东西。
（当然，我经常处理那些不关心平台的专家编写的科学计划，甚至不想独立编写平台）。
我第二个SvenW的意见，在其他线程的意见，并希望添加几个。
如果用户有一个漫游configuration文件会发生什么，我想通过GPO安装MSI？ 这是否意味着用户得到它或机器？ 多个用户使用同一台机器的情况如何？
如果configuration文件从他们应该运行的计算机移动到Uni实验室中不像打印服务器的位置，会发生什么情况？ 应用程序会跟进吗？
我如何控制版本，例如，如果它安装在另一台计算机上，configuration文件已迁移到新机器上？ msi不会在一致的状态下，当你释放一个新版本时，我可能不会捕获它，或者有什么可能会破坏？
确保您的可执行文件和您的数据是完全分离的有很好的安全性原因，另外在许多环境中，您可能无法期望用户对其appdata文件夹执行权限。
我不知道你的应用有多大，但是当我为configuration文件运行备份作业时，是否真的想为每个用户备份？
你的应用程序听起来真的是可移植的，自我包含，这很好，有解决上述每个问题。 但是，为什么摇摇晃晃的把它放在一个不应该去的地方，而把它放在预期的地方呢？ 我不能为其他人说话，但上述情况会使事情陷入“不可预测的”状态，这并不是很好。
至于谷歌，这取决于你的使用情况，他们推动了很多家庭用户，也许谁不在乎呢？ 您听起来像是您对企业IT的推动力，对于那些将testing和部署您的应用程序的人来说，这不会有什么坏处。 他们会花更less的时间想办法来取代它，如果你是稳定的，可预测的，像他们每个人一样工作。
软件限制策略在企业Windows环境中也很常见。 现代Windows的这个未充分利用的function允许pipe理员允许或限制基于path运行的可执行文件，甚至基于encryption签名。 我通常只允许可执行文件只能在Windows或程序文件目录中运行。 否则用户可以下载到AppData甚至他们的用户目录，基本上是运行任何东西。 如果用户可以运行任何他们想要的EXE，强迫用户成为有限的用户，这有什么意义呢？ 我为GoToMeeting制定了例外规定，但还没有Chrome。
是的，我介意。 原因很简单….漫游configuration文件。
虽然你的应用程序可能不是那么大，但是添加所有其他决定AppData是安装和configuration文件变得巨大的用户……用户login时间增加…而我们应该责怪慢速系统/networking（是的，这也适用于那些应该更了解的人）。
我很快就会被释放的AppLocker政策将杀死这些糟糕的Windows编程的例子，所以不会丢失。