locked
How to define outputfilename or at least change compilation unit file extension? RRS feed

  • Question

  • Hi all,

    I am developing a composite application which relies on plugins. In order to determine whether a file could be a plugin or not, we would like to introduce a file extension to it. Technically, our plugins are libraries. The request therefore is easy, how can we change the output filename of a library compilation?

    Example:
    Assembly Name: Acme.FirstStep
    Apl
    Results in compilation unit names: Acme.FirstStep.plugin (not .dll!)

    Whatever I change, either, it doesn't compile at all or it suffixes my input with .dll

    Having a look to the Macros defined for Build Events, I like to change the value of the 'TargetExt' macro. How can I do that (project based)? I am not familiar with MSBuild at all, but I tried:
    • Change AssemblyName in Project Properties, no effect on extension
    • Written some post build commands to rename. Works, but with side effects when the assembly is referenced by others (project reference results in 'wrong' reference to the output file, which is still .DLL).
    • Changed $(TargetExt) in the project file, no effect (see Microsoft.Common.targets ~line 99)
    • Changed $(TargetPath) in the project file, no effect.
    • Changed $(TargetFileName) to $(AssemblyName).myext, no effect expect on .config file.
    • Change @(IntermediateAssembly) in the project file, did not make it working.
    • Changed $(OutputType) to extension did not work either (after having a look to Microsoft.CSharp.targets)
    • Write an own build target. Running into side effects of missing references.
    • Command line option 'oname' could work, but how to use it from the project file?
    • Had a look to VSPackage samples outline several ways to get the output filename, but no one setting it. Did not find so far a sample on how to interact with the build process.
    (Using VS2008 30729.1 on Win7x64)

    Appendix:
    Just noticed, when I build with vs, it creates the following in the output window:
    C:\Windows\Microsoft.NET\Framework\v3.5\Csc.exe /noconfig /nowarn:1701,1702 /errorreport:prompt /warn:4 /define:TRACE;DEBUG /reference:....
    To me, it very much looks like that VS itself is not asking MSBuild to compile using the project file. In conclusion it appears pointless to edit the project file since VS won't extract the values from there. Assumption correct?

    I am wondering why it appears so tricky just to change the output filename of an assembly...

    Can anybody help? Which approach appears to be promising? Adjusting the project file or do something with VSPackage (like own project type)

    Thanks in advance,
    Sosum
    Monday, February 15, 2010 4:02 PM

Answers

  • Hi Sosum,

    Thanks for your post on MSDN forum.
    In my opinion, modifying project file, Microsoft.CSharp.targets and Microsoft.Common.targets is not a good/easy way, though VS is exactly running the targets in project file(csc.exe is called in CoreCompile target).  And as you noticed, many related area need to be care too, only changing $(TargetExt) won't take effect.

    I'm not sure what Command line option 'oname' is, is it a switch of MSBuild/Csc, or a command line program/script?  If it's a command line program/script, the MSBuild task Exec would help.

    Because the assembly is referenced by other projects, copying it to another place then renaming also won't work, gacutil.exe and static referencing won't recognize the suffixes different of .dll.  The only option I can think out is to replace the static referencing mechanism with dynamically loading, using reflection for the function calling.
    VSPackage has no any functionality on this requirement, to get more better idea, Visual C# forums could be a choice.

    Sincerely,

    Wesley Yao [MSFT]
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact: msdnmg @ microsoft.com
    Please mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Marked as answer by Wesley Yao Tuesday, March 2, 2010 3:45 AM
    Tuesday, February 16, 2010 6:40 AM

All replies

  • Hi Sosum,

    Thanks for your post on MSDN forum.
    In my opinion, modifying project file, Microsoft.CSharp.targets and Microsoft.Common.targets is not a good/easy way, though VS is exactly running the targets in project file(csc.exe is called in CoreCompile target).  And as you noticed, many related area need to be care too, only changing $(TargetExt) won't take effect.

    I'm not sure what Command line option 'oname' is, is it a switch of MSBuild/Csc, or a command line program/script?  If it's a command line program/script, the MSBuild task Exec would help.

    Because the assembly is referenced by other projects, copying it to another place then renaming also won't work, gacutil.exe and static referencing won't recognize the suffixes different of .dll.  The only option I can think out is to replace the static referencing mechanism with dynamically loading, using reflection for the function calling.
    VSPackage has no any functionality on this requirement, to get more better idea, Visual C# forums could be a choice.

    Sincerely,

    Wesley Yao [MSFT]
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact: msdnmg @ microsoft.com
    Please mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Marked as answer by Wesley Yao Tuesday, March 2, 2010 3:45 AM
    Tuesday, February 16, 2010 6:40 AM
  • Hello,

    How are you? Is your problem resolved? May I know whether the above suggestions helped you?

    Thanks,

    Wesley Yao [MSFT]
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact: msdnmg @ microsoft.com


    Please mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, February 24, 2010 2:59 AM