Comments (9)
After some further consideration of this issue, I'm realizing that the decisions of whether the DLLs should be copied somewhere or not, and of whether the destination is the output folder or some other arbitrary folder, are not for the package designer to make. They are for the package consumer to make, because this depends on their specific development environment: in our case, we must collect all 3rd party DLLs in one folder, and all of our own DLLs and EXEs in another folder (both said folders are separated by platform).
Therefore, instead of being able to specify a destination folder in a CopyToOutput-like command in package design time, what I probably really want is a way for the package consumer to specify the destination folder for all package DLLs. When it is unspecified, the DLLs should probably still be copied to the consuming project output folder (assuming it is not a static LIB project). When it is specified, the DLLs should be copied to the specified folder. This setting should depend on project configurations, e.g. to be able to vary by platform.
Note that the package consumer should be able to somehow set this globally (e.g. by a *.props file imported by many projects): in the scenario I described, many projects will use the same destination folder for 3rd party DLLs (varying only by platform), and it wouldn't make sense to specify it manually in each and every project (and in each project configuration).
Implementation idea (just brainstorming with myself): instead of specifying "$(TargetDir)" as the destination of the Copy task, specify a custom property "$(3rdPartyDllDir)". In the *.targets file of the package, specify a default value of 3rdPartyDllDir = "$(TargetDir)" on the condition that 3rdPartyDllDir isn't set. Then the project consumer can override this value to whatever, either directly in the project file or through another imported *.props / *.targets file. I would also support skipping the copying altogether if this is set to an empty string.
from coapp.powershell.
Some further refinement, if I may:
Other than my request that CopyToOutput will copy to a custom
Also, the actual target folder should be nested under the specified "global content folder" (see the last example here for recursive copying in MSBuild).
from coapp.powershell.
fyi: I'm stuck in out-of-office meetings until Friday; don't panic, I'll be back :D
from coapp.powershell.
I think you guys are right on the money here.
Doing this correctly shouldn't be too tricky. I think I can even generate the XAML property so that this will be overridable in the properties window.
I had an idea how to renovate the copy tasks a bit last night; it involves generating something in the .targets file that looks kinda like this:
<ItemGroup Condition="**generatedconditionstatement**">
<CopyToWhereverISay Include="somefile.xyz" />
<CopyToWhereverISay Include="some_more_files\**\*.abc" />
</ItemGroup>
<Target name="AfterBuild" >
<Copy SourceFiles="@(CopyToWhereverISay)" DestinationFolder="$(WhereverISayDestination)" />
</Target>
I'm pretty sure I can make all that work, it means we just have do define the destination folder, and way of saying which group the source files are to be combined with.
I'll keep the bin folder as targeting $(TargetDir) -- actually I'll make sure that it uses a folder copy instead of per-file by default, so that it will work naturally with a tree of files.
And then I'll add a way to add files to a collection, which we can associate to a Copy Task with a destination.
Hmm. Most of this would almost work right now if I had the #add-folder metatdata tack on \**
to the collection.
from coapp.powershell.
You have moved past my knowledge of how the MSBuild system works, but the solution above sounds like it has the flexibility we have been talking about. The only thing that I'm not sure about is the MSBuild CopyTaks. Doesn't the copy task flatten its input list of files into the output directory - so you'd loose the deep folder structure again? Also, would this structure be able to support multiple destination folders? Oh, that is the comment about using $(TargetDir)...
from coapp.powershell.
Live neck deep in this problem for the last five years, and you would quickly learn the deepest, darkest things about MSBuild.
The funniest part is that I wrote a prototype a few year ago of a build automation tool (what eventually became the invoke-build command in CoApp) that internally worked fairly similar to MSBuild . It wasn't very hard to move to using MSBuild for the underlying engine later...
The copy task maintains the folder layout (when used correctly :D )..
And, yeah, this will support multiple, arbitrary destinations.
from coapp.powershell.
Sweet! Thanks, and sorry for your pain. :-) (though I live neck deep in makefiles on Linux as part of my work, and I think MSBuild is better). And looking forward to testing what you've got. :-)
from coapp.powershell.
I've got a new Development version posted that supports this.(see the issue #27 thread for the example)
use
PS > update-coapptools –Development -killallpowershells
To update to my current Dev version (as of this moment, 2.4.164.0 )
As soon as I can get a bit more testing on this to make sure that it's at least fairly stable, and doesn't have any really broken things, I'll promote this to 'Beta'
from coapp.powershell.
Thanks, I've been able to get this to work much in the same way that gordonwatts has.
from coapp.powershell.
Related Issues (20)
- Publish-NuGetPackage doesn't publish symbol packages if -IgnoreRedist option is set.
- Dynamic versioning of locally built packages
- Provide a way to attach pdb to static libraries HOT 2
- Please release VS2015 support HOT 15
- Documentation on Website broken HOT 1
- readonly content HOT 1
- Make Main package independent from Redist HOT 4
- VS2015 C++. Not working IntelliSense and code navigation. HOT 1
- package with static libraries still has linkage dynamic? Help? HOT 4
- CoApp.Powershell.Tools does not compile
- CoApp.Powershell.Tools fails on _fileSet[String.Empty] key. Dictionary has no such key.
- First time build fails HOT 1
- Invalid URI: The format of the URI could not be determined. HOT 3
- Dynamic only packet not created when the word "static" is found into .autopkg file HOT 1
- Update to latest nuget version
- Future of CoApp project maintanance HOT 1
- Write-NuGetPackage : Illegal characters in path HOT 1
- Native c++ library symbol source not work on ProGet
- Clues to add VS 2017 support ? HOT 1
- CoApp Does Not Allow ASCII-Extended Characters During Package Creation
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from coapp.powershell.