rainersigwald on vsix-depend-on-nuget
VSIX dependency on NuGet.BuildT… Disambiguate branch name (compare)
livarcocc on vs16.0
Bump version to disambiguate wi… Merge pull request #4119 from r… (compare)
livarcocc on livarcocc-patch-1
livarcocc on vs16.0
Adding a vs16.0 trigger Updating to a more general trig… Merge pull request #4118 from M… (compare)
Directory.Build.propsget cached at all? reason I ask, I shifted gears in my assembly versioning strategy, and I am seeing evidence of the old strategy on the frist next build. If I re-run the build, seems to be fine, like the next properties got cached.
.csprojgets rolled up, including any build properties, imported projects, etc, and cached.
<Target Name="BumpAssemblyVersionsBeforeBuild" BeforeTargets="BeforeBuild" Condition="'$(TargetFrameworks)' == ''"><CallTarget Targets="GeneralBumpAssemblyVersions" /></Target>
<Target Name="BumpAssemblyVersionsBeforeDispatchToInnerBuilds" BeforeTargets="DispatchToInnerBuilds" Condition="'$(TargetFrameworks)' != ''"><CallTarget Targets="GeneralBumpAssemblyVersions" /></Target>
AssemblyInfo.csas the case may be indicates
x+1whereas the package output indicates
BeforeTargets="BeforeCompile;CoreCompile"... That should work then, in either single or multi target cases.
dotnet slntool is using a port of an internal solution representation from the Xamarin guys.
MSBuildWorkspaceand add a project to the solution. I get a new solution as a result and ask
TryApplyChanges. Now if I changed something like a document or a project, then the changes persist. But if I changed something about the solution file, the changes do not persist.
Documentobjects are all immutable. If you change a
SyntaxNode's, for example, that produces a new
Documentobject in a new
Projectwithin a new
Solution. That change lives in memory until you call
TryApplyChanges, at which point the workspace will have a new
Solutioninstance assigned to its
MSBuildWorkspaceI think of MSBuild's implementation of the Roslyn workspace. Roslyn itself has an object model for these things but doesn't necessarily have the code to do IO, and MSBuild is the 'manager' of the files (at least the build system ones). That view might be incorrect though.