Skip to content
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

DependentUpon not always set successfully in new-style MSBuild projects #16

Open
idg10 opened this issue May 1, 2017 · 0 comments
Open

Comments

@idg10
Copy link

idg10 commented May 1, 2017

Installed product versions

  • Visual Studio: 2017 Enterprise v15.1 (26403.7)
  • This extension: v1.0.12
  • Windows 10 Creators Update (up to date as of 2017/05/01)

Description

When generating the typescript file, the extension attempts to arrange for Solution Explorer to show the generated file nested inside the .cs file from which it was generated, by setting the generated file to be DependentUpon the .cs file. This intermittently fails when working with projects that use the new-style MSBuild templates introduced with Visual Studio 2017.

Steps to recreate

  1. Create a new project with the Class Library (.NET Standard) template. (ASP.NET Core Web Application (.NET Framework) also produces same issue)
  2. Add a Models folder
  3. Create a class called Child with two properties: public int NumericValue { get; set; } and public string TextValue { get; set; } (simpler probably works, but this is what my repro does)
  4. Right click on the project item and select Generate TypeScript Definition

NOTE: I cannot get this to repro if I'm debugging the Visual Studio instance. I was trying to work out why this problem was occurring before reporting it: I downloaded a copy of the source, built it, and configured VS to launch another instance of VS in the Exp hive. But I find that with the debugger attached, this problem tends not to repro. There's presumably some sort of race around when the operation kicked off by Dispatcher.CurrentDispatcher.BeginInvoke in GenerationService.CreateDtsFile gets around to executing, and attaching the debugger changes the order of events.

Current behavior

Sometimes the generated file will appear as its own separate project item, instead of being nested inside the corresponding .cs item. Sometimes you can 'fix' this by making a meaningless edit to the .cs file and saving it again, at which point the generated TypeScript file will sometimes (but not always) change into a child of the .cs file.

Expected behavior

The generated file should always always appear as a child of the corresponding .cs file after you first enable generation, instead of randomly sometimes not doing this.

Comments

The fact that you needed to defer execution through CurrentDispatcher.BeginInvoke presumably means you need to wait for the project system to catch up with the addition of the generated file. It looks to me like deferring until the dispatcher gets to DispatcherPriority.ApplicationIdle is not enough - it can take longer than that for it to work. I tried modifying the relevant code to work like this:

DispatcherTimer dt = null;
dt = new DispatcherTimer(
    TimeSpan.FromMilliseconds(100),
    DispatcherPriority.ApplicationIdle,
    (s, e) =>
    {
        var dtsItem = VSHelpers.GetProjectItem(dtsFile);

        if (dtsItem != null)
        {
            dtsItem.Properties.Item("DependentUpon").Value = sourceItem.Name;
            dt.Stop();
            Telemetry.TrackOperation("FileGenerated");
        }
    },
    Dispatcher.CurrentDispatcher);
dt.Start();

That seems to work for me. I don't much like this - polling seems like an unsatisfactory solution. Perhaps VS's extension APIs provide some better way to be notified of when project items update, or transition into some sort of 'ready' or 'available' state. But in any case, this supports my hypothesis that the problem I'm seeing occurs because this extension sometimes attempts to set up the DependentUpon relationship before VS is ready.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant