-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Throw an error if the Sdk attribute contains any expandable characters #1518
Comments
What about Import tags' Sdk attribute? For e.g.: <Import Sdk="$(DynamicSdk)" /> It'll be useful in an injection scenario! Does it work? If not, will it be supported? |
At this time the <Project>
<!-- common.props defines $(DynamicSdk) -->
<Import Project="..\common.props" />
<Import Project="Sdk\Sdk.props" Sdk="$(DynamicSdk)" />
...
<Import Project="Sdk\Sdk.targets" Sdk="$(DynamicSdk)" />
</Project> Every time you made a new project you'd have to hand edit it and add the imports. |
Well, that may be so but not exactly.
These are the ones I'm currently dealing with. |
Can you explain this?
<Project Sdk="Microsoft.NET.Sdk">
<Import Project="Sdk\Sdk.props" Sdk="$(DynamicSdk)" />
</Project> If you're adding an import to every project, it would be just as easy to just do:
You would still need to default
That seems less then ideal |
<Project Sdk="Microsoft.NET.Sdk">
<Import Project="Sdk\Sdk.props" Sdk="$(DynamicSdk)" />
</Project> Yes. But within the Base Sdk itself. For e.g. say I have two types of Packaging or Bundling targets like nuget. I would do this <Project Sdk="Custom.NET.Sdk">
...
<BundlingSystem>CabBundler</BundlingSystem>
...
</Project>
Then in the Base SDK, I would resolve the above property to SDK name and set the property to that resolved Sdk package. For e.g. In the props and targets of the <Project>
...
<ResolvedBundlerSdk Condition="'$(BundlingSystem)' == 'CabBundler'">Bundler.Cab.Sdk</ResolvedBundlerSdk>
<Import Project="Sdk\Sdk.props" Sdk="$(ResolvedBundlerSdk)" />
...
</Project> Little bit of something I'm working on. |
This is not setting different global SDKs but using different SDKs with specific functions within the master SDK without creating a duplicate set of targets as a nuget package. For e.g.: NuGet team can have one master Sdk that does have all the tasks and targets but can also have a separate targets (Sdk) package that is referenced by the master package. And also by other teams that want the functionality like Packaging but disabling the other features that comes with master Sdk. |
<Project>
...
<Import Project="Sdk\Sdk.targets" Sdk="1.Sdk" />
<Import Project="Sdk\Sdk.targets" Sdk="2.Sdk" />
<Import Project="Sdk\Sdk.targets" Sdk="3.Sdk" />
...
</Project> OR <Project>
...
<Sdk Name="1.Sdk" Version="1.0" />
<Sdk Name="2.Sdk" Version="2.1" />
<Sdk Name="3.Sdk" Version="3.2" />
...
</Project> If this is possible. Even cleaner! |
Right now the Sdk value is treated as a literal string with no expansion. If a user specifies something like:
Then the value "$(Property1)" is passed to the resolver which would probably return a message stating that it couldn't be found. We should instead check if the value contains expandable characters and throw an invalid project error.
The text was updated successfully, but these errors were encountered: