You're doing it correctly (and the command line is the only way to do it), however I have to ask why you're adding references to your publisher policy file from other projects? Publisher policy files are a deployment-only consideration and should not be referenced by other project (and there's no need to, since there's no Types in it).
One other thing to clarify for technicality's sake... You mention that the config file has to be added as a resource to an assembly, that's not quite right. It has to be a "linked resource" or "external resource" to an assembly, which is what the /linkresource switch does. It keeps the .config file outside of the assembly but creates an entry in its manifest to the external resource. This is one reason you can't do it from VS.NET, there's no way to indicate a linked resource, only an embedded resource. To verify in ILDASM, open up the MANIFEST and look for .mresource entries. You should see an external resource in your command-line compiled policy file; compare that to the VS.NET generated one. Adam.. > -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Bill Bassler > Sent: Tuesday, August 16, 2005 6:52 AM > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: [ADVANCED-DOTNET] Possible to create a publisher > policy assembly from a VS.Net project > > I'm currently creating a publisher policy assembly by running > the following command within a Pre Build event for a VS.Net > project that also creates the assembly that the policy is > for. In this way, both assemblies are easily able to use the > same strong-name key file and the binding redirect config is > properly added as resource to the assembly. > > cls > call "$(DevEnvDir)..\Tools\vsvars32.bat" > al /linkresource:..\..\Policy\policy.1.0.Types.config > /out:..\..\Policy\pol icy.1.0.Types.dll > /keyfile:..\..\Types.snk /version:1.0.* /productversion:"1 .0" > > As you can see the resulting resource assembly is created in > a folder called Policy within the project. From there, I use > a merge module and a reference to the resulting asembly to > GAC the policy assembly. The problem with this way of doing > things is that VS.Net has multiple, nested references to the > policy assembly, it tries to alway check in the dll and this > creates havoc with VS.Net's path based referencing situation > and Visual SourceSafe's default check in behavior. > > What I'd like to be able to do is simply create a VS.Net > project called: > policy.1.0.Types, place the binding redirect file within it, > reference the strong-name key file of the original assembly > that the policy is for; through something like "Add an > Existing Item" and have the policy file be the output of this > project;Not have the policy assembly be created in a sub- > folder. However, if I create a project like the the version > redirection doesn't appear to work. > > I found some docs that state that the binding redirect xml > must be added as a resource to the assembly (which is what > the linkresource switch does in the command, of course) but I > haven't found the correct way to do this; obviously. I also > tried running the command above from a Post build event in > the policy.1.0.Types project in order to simpley rewrite the > assembly with the linked resource after the intial build this > doesn't appear to work. > > What am I doing wrong? There has to be a non-command line > VS.Net project- based way to just add the binding redirect > config file as a resource. It seems like just adding the file > to the project isn't enough. ILDasm isn't any help because > I'm not sure what I'm looking for in the policy assembly to > determine if it's properly compiled. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
