NTrace V2.0.118.0 (Beta) feedback

May 1, 2011 at 8:44 AM

Hi,

Please find below my feedback on latest version of NTrace:

  1. Clean install (after removing previous version) went perfectly fine - didn't test upgrade scenario.
  2. I've noticed 2 folder under installation folder: v2.0 and v4.0. What is the v4.0? which one should I use when referencing from a project?
  3. After installation, existing NTrace projects could not be opened - failed with import project which specifically points to v1.1 location (i.e. <Import Project="$(MSBuildExtensionsPath)\NTrace\v1.1\NTrace.CSharp.targets" />). I had to manually edit the project file and fix this (changed v1.1 to v2.0, hope this is what I should have done)
  4. The problem of NTrace preprocessor not showing the exact error location still exists
  5. Could not create new NTrace based project - the when selecting instrumented console application in new project wizard, I had to 'VS installed Template' (which I have no clue what it is) - when I chose the 1st one (.devenv), I got an error message that project file '.devenv.exe' doesn't exist and the new project wasn't created.

All tests were done on VS2008.

Thanks,

--Eran

May 1, 2011 at 12:03 PM

In addition, I can't find how to use the new VS2008 integration - edit the provider ID, trace helper class name, and especially the lists of flags and levels.

Thanks,

--Eran

May 1, 2011 at 2:18 PM

One more thing - on my of my recent posts I've asked about components and sub-components, and was replied it will be handled in v2.0 - looking at the trace's output using TraceView shows that those fields are still empty,

Did I miss anything?

Coordinator
May 1, 2011 at 4:35 PM

Hi! Thanks for testing the new version.

On the 2.0 versus 4.0 folder; it's about the fact that the 2.0(and 3.X) and 4.0 frameworks are different runtimes. I'll add a task to explain the need for and use of these folders.

Re: backwards compatibility, I haven't tackled that one yet, but it hopefully should be as simple as replacing those .targets files with copies that directly import the 2.0 .targets file.

I'm disappointed to hear that you are still getting the vague preprocessor error! I did a lot of refactoring to make the errors more informative. If there is any way for you to provide a test project that I can use for testing, that would help a lot.

I'm afraid I haven't encountered the error you're describing with the 'VS installed template.' You should just see the standard "Instrumented XXX" projects under the C# Projects node. If you look under your <<VS 9.0>>\Common 7\IDE\Project Templates\CSharp\Windows folder, do you see the .zip files for the Instrumented projects? If you do see them, try running "devenv.exe /installvstemplates" to get VS to refresh its cache.

On the components; NTrace now installs a Visual Studio package that delivers a property page for instrumented projects. This property page allows you to modify the list of components (flags) that you can associate trace messages with, and this set of flags can be used in your EtwTrace.Trace() calls by using the overloads that take EtwTraceFlag parameters.

If you are retrofitting an existing project to use this VSPackage, you need to add a ProjectTypeGuids element to your project such as:

<ProjectTypeGuids>{05D5C7B2-D255-4162-AE48-596FE4FBCCB9};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

May 2, 2011 at 2:26 PM

Hi Andi,

I'm mailing you a test project to test the vague preprocessor error - this is a VS project which reproduces the problem.

As for the creation of new projects issue I've had, running "devenv.exe /installvstemplates" indeed fixed the problem.

Also, adding the ProjectTypeGuids to the project file added NTrace tab to the project properties and enabled editing the flags. I have a follow-up question on that, though:) TraceView displays level and flags by their numerical values (i.e. displayning numbers), is there a way to format/parse the trace so it will show names instead of numbers? What about 'Component' and 'Sub-Component' fields available in TraceView - is there a way to use them in NTrace?

Thanks much,

--Eran

May 2, 2011 at 2:28 PM
Please find attached a test project for the vague error message issue.


From: [email removed]
To: [email removed]
Date: Sun, 1 May 2011 09:35:48 -0700
Subject: Re: NTrace V2.0.118.0 (Beta) feedback [NTrace:255859]

From: ahopper
Hi! Thanks for testing the new version.
On the 2.0 versus 4.0 folder; it's about the fact that the 2.0(and 3.X) and 4.0 frameworks are different runtimes. I'll add a task to explain the need for and use of these folders.
Re: backwards compatibility, I haven't tackled that one yet, but it hopefully should be as simple as replacing those .targets files with copies that directly import the 2.0 .targets file.
I'm disappointed to hear that you are still getting the vague preprocessor error! I did a lot of refactoring to make the errors more informative. If there is any way for you to provide a test project that I can use for testing, that would help a lot.
I'm afraid I haven't encountered the error you're describing with the 'VS installed template.' You should just see the standard "Instrumented XXX" projects under the C# Projects node. If you look under your <<VS 9.0>>\Common 7\IDE\Project Templates\CSharp\Windows folder, do you see the .zip files for the Instrumented projects? If you do see them, try running "devenv.exe /installvstemplates" to get VS to refresh its cache.
On the components; NTrace now installs a Visual Studio package that delivers a property page for instrumented projects. This property page allows you to modify the list of components (flags) that you can associate trace messages with, and this set of flags can be used in your EtwTrace.Trace() calls by using the overloads that take EtwTraceFlag parameters.
If you are retrofitting an existing project to use this VSPackage, you need to add a ProjectTypeGuids element to your project such as:
<ProjectTypeGuids>{05D5C7B2-D255-4162-AE48-596FE4FBCCB9};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
Read the full discussion online.
To add a post to this discussion, reply to this email (NTrace@discussions.codeplex.com)
To start a new discussion for this project, email NTrace@discussions.codeplex.com
You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.
Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com
Coordinator
May 2, 2011 at 5:07 PM

Argh! You managed to find the one place where I wasn't including the file name/line number in the error. This will be fixed in the next drop.

Coordinator
May 2, 2011 at 6:05 PM

On the component/sub-component question: I'll have to do some research on this one; the docs are infuriatingly terse on this feature. Theoretically, if native tracing offers it, we should be able to as well; it's just a matter of finding the appropriate knobs to turn.

Coordinator
May 3, 2011 at 1:06 AM

Good news, everyone!

We can in fact support names for components/sub-components, but I'll need to figure out how to can integrate it in a usable manner. Right now, I see three possible ways to set the component info (stated in order of preference):

  1. In the project (a UI can be added to the property page). This would limit you to a component/subcomponent per project, but this is reasonably close to how you set things up in the unmanaged world. Multiple projects could share a component name (as well as the provider ID, but that's a different show), and use a subcomponent to qualify their trace output.
  2. In the trace call itself as an additional overload. This would work, but I have concerns about how usable such an approach would be. Imagine having to specify component/sub-component every time you add a trace call; blech.
  3. By specifying a list of trace pseudoclasses (The "EtwTrace" in your friendly neighborhood EtwTrace.Trace) that each map to component/subcomponent combinations. This is certainly less verbose than 2), but has two problems: first, it would require support for multiple pseudoclasses from the preprocessor, and second, it could make life interesting if/when we have name collisions (I can confidently state that anyone who names their class EtwTrace is just looking for trouble, but I'll have a hard time explaining why it's not my fault when things suddenly break due to a name collision with something like IO).

Right now, I'm inclined to use 1), with the possibility of adding 2)'s ability to override the project-level values on a per call basis in a subsequent release. Since you're the only person who has asked for this to-date, you get to be the founding member of the NTrace Component Name Support focus group! I'm curious as to what your use cases would be, as they may change the approach we want to use...

-Andy

May 3, 2011 at 9:02 AM

These are great news, indeed!

Having the combination of 1) and 2) (although in separate releases) sounds just fine.

As for my use cases for NTrace - I'm working on a relatively large project with 10s of project files and hundreds (or more) classes. As I see it, ideally component is mapped to project file, and sub component to a class.

Having single component/subcomponent per project (which is (1) if I understood correctly) in the 1st release, will do with adding finer granularity by using flags, for example.

Let me know if you need more details.

--Eran

May 11, 2011 at 8:36 AM

Hi,

I've tested the beta refresh build (141) and found that the bug of the missing error location (file/line) is indeed fixed for NTRC0508 error as well.

Do you have any estimation when the new components\sub-components feature discussed below will be available? Is there a chance that it will be in the current release?

--Eran

Coordinator
May 11, 2011 at 9:48 AM

Ah, splendid!
The work to add the component/sub-component support is underway, so it's not in the current drop. I should have that ready in the next week or so.

On May 11, 2011 4:37 AM, "eranhare" <notifications@codeplex.com> wrote:
> From: eranhare
>
> Hi,I've tested the beta refresh build (141) and found that the bug of the missing error location (file/line) is indeed fixed for NTRC0508 error as well.Do you have any estimation when the new components\sub-components feature discussed below will be available? Is there a chance that it will be in the current release?--Eran
>
>
May 11, 2011 at 11:29 AM

By 'current release' I meant 'in the time-frame of release 2.0.*' (I didn't expect that to be on 141) - next week or so sounds just great. Looking forward to test it:)