MSBuild: importing files before and after Microsoft.CSharp.targets

[Anton Shepelev]

Hello all,

I want to automate the obfuscation of my projects
using dotfuscator, in the Release configuration. To
do that, I have created an MSBuild file specifying
the following post-build event:

SET OUT=$(ProjectDir)$(OutputPath)
SET SRC=%OUT%$(AssemblyName)$(TargetExt)
: The following line removes trailing slash
SET OUT=%OUT:~0,-1%
dotfuscator /controlflow:high /naming:unprintable /enhancedOIn /in:"%SRC%" /out:"%OUT%"
: Remove the default output directory for map files:
rmdir /s /q .\Dotfuscated

In order for it to work, this file must be included
after Microsoft.CSharp.targets, while some of my
other settings are specified in another MSBuild file
that must be included before it. This means that
the changes to the main .csproj file must be made at
two different points. Is there a way to keep them
at one place and in one MSBuild file?

 

[Arne Vajhøj]

I want to automate the obfuscation of my projects
using dotfuscator, in the Release configuration. To
do that, I have created an MSBuild file specifying
the following post-build event:

SET OUT=$(ProjectDir)$(OutputPath)
SET SRC=%OUT%$(AssemblyName)$(TargetExt)
: The following line removes trailing slash
SET OUT=%OUT:~0,-1%
dotfuscator /controlflow:high /naming:unprintable /enhancedOIn /in:"%SRC%" /out:"%OUT%"
: Remove the default output directory for map files:
rmdir /s /q .\Dotfuscated

In order for it to work, this file must be included
after Microsoft.CSharp.targets, while some of my
other settings are specified in another MSBuild file
that must be included before it. This means that
the changes to the main .csproj file must be made at
two different points. Is there a way to keep them
at one place and in one MSBuild file?

This question reminded me of a previous question you asked.

The executable of my plugin host system uses several
assemblies, and must be provided as a single file,
so I've decided to build the dependencies into the
executable as "embedded resources" using this trick:

http://stackoverflow.com/questions/189549/embedding-dlls-in-a-compiled-executable/
(also see reply by Ant_222, who is me)

How can I make Visual Studio update the included bi-
naries automatically every time they are rebuild?

Currently I'm copying them into the main project's
IncBin directory in the pre-build event, but that
requires trickeration with SoruceSafe to make those
files readable while not checked out, so that sever-
al developers can build and run it simultaneously.
Is there a better way?

I think you are attacking the problem from the wrong
direction.

You should separate your development and build.

You develop in VS and have a csproj that supports
what you need to develop and debug your code.

You make production builds using extract from
source control and standalone msbuild using a
completely different handwritten csproj that does
exactly what you want for the real build.

That way you avoid the VS vs production build
conflicts completely.

If you want to make it a bit more sophisticated,
then you start using a CI tool.

Arne

 

[Anton Shepelev]

Arne Vajhoj:

This question reminded me of a previous question you asked.



I think you are attacking the problem from the wrong
direction.

You should separate your development and build.

Yes. I plan to develop in Debug mode and build in
Release mode. Since sometimes I have to run the de-
bug version at a client, I embed .dll's in both De-
bug and Release modes, but I don't want to Dotfus-
cate in Debug mode.

You develop in VS and have a csproj that supports
what you need to develop and debug your code.

You make production builds using extract from
source control and standalone msbuild using a com-
pletely different handwritten csproj that does ex-
actly what you want for the real build.

Doesn't it introduce duplication, e.g. to add a file
or reference to the project I have to modify two
..csproj files: one for VS and one for MSBuild? My
currenty .csproj for VS are hand-written already,
because VS makes them messy, so I only modify them
manually.

If you want to make it a bit more sophisticated,
then you start using a CI tool.

Not ready for it yet, because CI is way much more
than separating devepment and build.

 

[Arne Vajhøj]

Arne Vajhoj:


Yes. I plan to develop in Debug mode and build in
Release mode. Since sometimes I have to run the de-
bug version at a client, I embed .dll's in both De-
bug and Release modes, but I don't want to Dotfus-
cate in Debug mode.


Doesn't it introduce duplication, e.g. to add a file
or reference to the project I have to modify two
.csproj files: one for VS and one for MSBuild? My
currenty .csproj for VS are hand-written already,
because VS makes them messy, so I only modify them
manually.

I would let VS maintain the development csproj and maintain
the build csproj manually using a traditional build script
style not in any way like VS creates it.

Not ready for it yet, because CI is way much more
than separating devepment and build.

True, but separation is a requirement to use a CI tool.

Arne

 

[Anton Shepelev]

Arne Vajhoj to Anton Shepelev:

I would let VS maintain the development csproj and
maintain the build csproj manually using a tradi-
tional build script style not in any way like VS
creates it.

Thank you for the reply.

But am I right in assuming that you have to make
parallel modifications to the two .csproj files? I
don't like it...

As for my original question, I have solved it by
checking the build configuration inside the post-
build event:

Setlocal EnableDelayedExpansion

IF "$(Configuration)"=="Release" (
SET OUT=$(ProjectDir)$(OutputPath)
SET SRC=!OUT!$(AssemblyName)$(TargetExt)
: The following line removes trailing slash
SET OUT=!OUT:~0,-1!
dotfuscator /controlflow:high /encryptn /naming:unprintable ^
/enhancedOIn /in:"!SRC!" /out:"!OUT!" > $(ProjectName).dfc
rmdir /s /q .\Dotfuscated
)