Costura doesn't remove assemblies from build folder about costura

[distantcam]

I might have a fix for this, but it requires patching the build system. I'll keep experimenting.

[SimonCropp]

Patching the build system??? U r making me nervous. Msbuild is very
fragile.

On 18/02/2013, at 6:22 PM, Cameron MacFarland [email protected]
wrote:

I might have a fix for this, but it requires patching the build system.
I'll keep experimenting.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/3#issuecomment-13709208.

[distantcam]

Patching the build system??? U r making me nervous. Msbuild is very
fragile.

Pish posh! You just have to know how to hold it right. 😈

[distantcam]

Commited a fix for this on my branch. If you're happy with this I'll merge it in.

220d25f
3c95282

Did you want me to just take over this project?

[SimonCropp]

more than happy for you to take it over :)

[SimonCropp]

@distantcam have u push and updated version that fixes this?

[SimonCropp]

some points

1. I am really not sure the hoops you have jumped through are worth it when this is only a "nice to have"
2. I dont think it will work with package restore. your Copy-Target will not run on restore so people wont have a copy of the targets. Or are people meant to check in the targets? If they are it kind of voids the whole "dont check in packages" approach of nuget.
3. the targets approach makes it very "non standard" compared to every other fody weaver. If you want to stick to this approach you need to consider how you will educate users abour the difference. I have already had questiosn from 3 people asking about the targets file.

Either way there needs to be some doco around this

[johnsimons]

👎
Does it really matter if the dependency file is referenced, when still developing?
To me what is important is that when I package my project and do not add the dependency file that is embedded, the app works, and that all comes to testing it.

[distantcam]

It works with package restore because the nuget package copies the target file outside the package to the same place Fody is, which is then presumably checked in. I know the experience of a nuget package adding a target file, only to have said target disappear when deleting the packages folder coughMicrosoft.Bcl.Buildcough

For development, if there is a problem it provides immediate feedback, rather than developing, committing, waiting for build, having app tested and then finding a problem.

Still, if this is an unpopular feature, or it causes too much confusion I can take it out.

[SimonCropp]

@distantcam

it is not an unpopular feature. the feature is valid.
But with the current implementation it is a trade off. the options are

1. not having this feature and educating people that the references are not deleted
2. having this feature and educating people on the targets qwerk

So Option 1 required people to know something. Option 2 requires people to know something and do something.
Also option 2 requires more code on our side.

So I would fall slightly on the Option 1 side.

But i am not adamant about it. I will leave it up to you.:)

[distantcam]

Well, I am in favour of a smaller codebase. And I'm a fan of KISS principle.

I'll change it back. ;)

On 27/02/2013, at 8:14 AM, Simon Cropp [email protected] wrote:

@distantcam https://github.com/distantcam

it is not an unpopular feature. the feature is valid.
But with the current implementation it is a trade off. the options are

1. not having this feature and educating people that the references are
   not deleted
2. having this feature and educating people on the targets qwerk

So Option 1 required people to know something. Option 2 requires people to
know something and do something.
Also option 2 requires more code on our side.

So I would fall slightly on the Option 1 side.

But i am not adamant about it. I will leave it up to you.:)

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/3#issuecomment-14148498
.

[SimonCropp]

should we close this? and perhaps document it somewhere?

[distantcam]

@SimonCropp I want to add the build script to the source, and then add a wiki page describing how to use it. Then I'll close this issue.

[SimonCropp]

go for it

[nmarler]

Hello - I'm looking for a little more guidance on this topic. FAQ "Creating a clean output directory" ends with "this does not handle ExcludeAssemblies or IncludeAssemblies options mentioned above. You will have to handle these explicitly."

I'm running into exactly that problem with ExcludeAssemblies - I have excluded two assemblies, but they are being deleted during the output directory clean up operation. I guess I don't know my way around project files or the build process very well, so I don't know how to "handle them explicitly" as the FAQ suggests. Can you provide some guidance? Thanks

[distantcam]

@nmarler For now, just remove the target from your project. There's no harm in having all the assemblies there.

This has given me an idea. We could make the target added to the project smarter and automatically exclude the assemblies from cleanup. Gonna create an issue to discuss this.