Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
2 Pages12>
Build failure - no space before base class
Options
Previous Topic Next Topic
johnmwright
#1 Posted : Tuesday, April 24, 2012 1:26:29 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
I started running NCrunch on a new C# project today and had some weird behavior I wanted to pass along.

Initially, NCrunch was unable to build one of the VS projects, with the message "ViewModels\SelectableField.cs (10): The type of namespace 'ViewModelBase' could not be found (are you missing a using directive or an assembly reference?)". This was listed for several files, each had the following general design:


In folder 'ViewModels':
Foo.cs:

public class Foo: ViewModelBase
{/*some code*/}

ViewModelBase.cs:
public abstract class ViewModelBase : INotifyPropertyChanged
{ /*some code */ }


Initially, I tried changing the "Copy referenced assemblies to workspace" option to true for this project and each of it's dependent projects, with no change.

However, in attempting to reproduce this issue, I noticed that if I edit the derived classes to add a space between the class name and the ":", NCrunch was immediately able to compile that class. For example, I changed "public class Foo: ViewModelBase" to "public class Foo : ViewModelBase", and it started compiling. Strangely, removing the space (returning to the original text) did not cause the error to return.

I'm not able to reproduce the issue in a new project, so I'm not sure what the core issue really is. I have a local fix (editing the failing files to add the space), so I'm not blocked, but wanted to pass this along in case others saw the same issue or you came across code that might be problematic.

I'm running NCrunch v1.38.0.17b in VS 2010 Premium v4.0.30319 SP1Rel
Back to top
 |  Edit by user
Remco
#2 Posted : Tuesday, April 24, 2012 10:03:12 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Hi, thanks for posting!

This is caused by a synchronisation issue between NCrunch and your codebase. Somehow NCrunch has managed to establish a slightly warped picture of the class you were having difficulty with, and by changing the class, you've triggered NCrunch to re-synchronise its contents and correct the issue. I haven't seen this happen for quite a while now - so I suspect the hole is probably small and difficult to undercover. Pressing the Reset button (or enable/disable) will always resolve issues like this. If you can find a consistent way to reproduce this problem, please do let me know as I'd love to fix it.


Cheers,

Remco
Back to top
johnmwright
#3 Posted : Tuesday, April 24, 2012 10:05:58 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
It's happened again when I added a new class to the folder with my ViewModels. Touching the files that NCrunch was complaining about allowed it to re-sync and build. If I'm able to recreate this again, is there any data in particular that would be useful to you in troubleshooting?
Back to top
Remco
#4 Posted : Wednesday, April 25, 2012 1:11:50 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Absolutely - if you can send through a bug report straight after it happens, that would be excellent. Also would be good if you can provide any specific details about which change you made to the codebase to surface the issue.

Considering how frequently this is happening for you I suspect there is something unique in your workflow or solution that is triggering it.
Back to top
johnmwright
#5 Posted : Wednesday, April 25, 2012 8:38:42 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
The error occurred again and I have submitted a bug report via visual studio titled "build failure - files out of sync" with the following message:


NCrunch is saying "The type of namespace 'ViewModelBase' could not be found (are you missing a using directive or an assembly reference?)". The "ViewModelBase" is the base class for each of the files which are failing to compile. They are all in the same folder of the same VS 2010 C# project.

Directly before seeing the error, I had moved a file from a subfolder into it's parent folder using drag-and-drop in the Solution Explorer window. This change was in a different folder than the ViewModelBase, but in the same project. The times I've seen this error before seem to occur when adding/moving files in that same project.

I'm not sure if it matters, but the file I moved is a sample file from Microsoft and the namespace for that file is set to Microsoft.Crm.Services.Utility, whereas the remainder of my project all use namespaces begining with my company's name.

--
After submitting the bug report, I was able to clear the build errors by going into each of the files listed in the NCruch Test output window and touching the file (removing, then re-adding a line feed).

I attempted to reproduce this issue in a separate visual studio project, but have been unsuccessful.

Let me know if there's any additional information that would be helpful.
Back to top
johnmwright
#6 Posted : Wednesday, April 25, 2012 9:09:42 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
I'm able to reliably reproduce the issue in my project by using the "Unload Project" menu option in solution explorer. Immediately upon unloading the project NCrunch generates the error messages I've been seeing, and reloading the project does not make them go away. As before, touching the files clears the errors. Also of note: it appears to be the same 7 or so files each time.
Back to top
 |  Edit by user
Remco
#7 Posted : Wednesday, April 25, 2012 9:45:26 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Nice testing. What is the encoding used for these files as they are stored on disk?
Back to top
johnmwright
#8 Posted : Thursday, April 26, 2012 9:28:20 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
Just the standard encoding used by visual studio when you say "Add New" and select a C# file.
Back to top
Remco
#9 Posted : Thursday, April 26, 2012 10:06:19 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Sorry, a few more questions to help to better understand what is happening:

- Are there any other references from the failing project(s) to types within the project that contains ViewModelBase? Do any of these references throw errors?
- Are you using the 'Copy assembly references to workspace' NCrunch configuration option for any of the projects in your solution?
- Do you have any additional complexity in your build process? Such as 3rd party tools, pre/post or custom build steps, etc
- Does the problem resolve itself if you unload/reload the ViewModelBase project (to cause the problem), then try to rebuild one of the failing depending projects by right-clicking on it in the Tests Window and choosing to rebuild?
- Is there anything unusual about the way in which the ViewModelBase project is being referenced? For example, is it perhaps referenced using an <AssemblyReference> in the .proj file instead of a <ProjectReference>, or are you using the InternalsVisibleTo assembly attribute?
Back to top
johnmwright
#10 Posted : Monday, April 30, 2012 1:38:00 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
It seems that I have once again lost the ability to reproduce this issue, as unloading/loading the projects in the solution no longer force the errors. The below answers are to the best of my recolection from when the errors were occurring.

- Are there any other references from the failing project(s) to types within the project that contains ViewModelBase? Do any of these references throw errors?

The failures were contained to the project that also contained ViewModelBase. One of the failures (mentioned in this post: http://forum.ncrunch.net...ut-has-wrong-count.aspx) was a class in the UI project calling into the constructor of a class in the Common project. The other errors were, as far as I can tell, restricted to classes in the UI project calling each other.
The project structure looks something like the below graph. Note: each of these is a library. The UI project and the AlternativeEntry project are both "plugins" to other applications.

MySolution
|- UI_Project
| |- Controls
| | |- Control1.xaml
| | | `- Control1.cs
| | `- Control2.xaml
| | `- Control2.cs
| |- ViewModels
| | |- ViewModelBase.cs
| | |- Control1ViewModel.cs
| | `- Control2ViewModel.cs
| |- Class1.cs
| `- Class2.cs
|
|- Common_Project
| |- Class1.cs
| `- Class2.cs
|
|- AlternativeEntry_Project
| |- Class1.cs
| `- Class2.cs
|
`- UnitTesting_Project
. |- Class1.cs
. `- Class2.cs

- Are you using the 'Copy assembly references to workspace' NCrunch configuration option for any of the projects in your solution?

Not currently, although at one point I turned it on for the UI project, then also the Common project, to see if it resolved the issues, but it did not, so I turned it back off.

- Do you have any additional complexity in your build process? Such as 3rd party tools, pre/post or custom build steps, etc

At the time of my original posting, the answer is "no". However, I've since added a post-build step to the AlternativeEntry project that copies the .dll file to additional locations in the solution folder structure.

- Does the problem resolve itself if you unload/reload the ViewModelBase project (to cause the problem), then try to rebuild one of the failing depending projects by right-clicking on it in the Tests Window and choosing to rebuild?

No. The only method I could find to resolve the issue was to manual edit each individual file that was listed as failing. Upon editing the one file, it would be removed from the list, as NCrunch would immediately register the change and recompile, however the remaining files would stay on the list until I had touched each in turn. (Re)Building from Visual Studio and/or from the NCrunch tests console had effect.

- Is there anything unusual about the way in which the ViewModelBase project is being referenced? For example, is it perhaps referenced using an <AssemblyReference> in the .proj file instead of a <ProjectReference>, or are you using the InternalsVisibleTo assembly attribute?

The references between projects in the solution are all project-based references. However, I am using the InternalsVisibleTo attribute within the Common project, which has no public API and all access from the other three projects is granted via internal visibility. Additionally, the UI, Common and AlternativeEntry projects grant InternalsVisibleTo to the unit test project.

Also of note: the ViewModelBase class itself is very straightforward. It implements INotifyPropertyChange with a single event PropertyChangedEvent and a property-name lookup helper method based on this: http://wrightthisblog.bl...roperty-references.html

One other somewhat non-standard thing that might be interesting:
My company uses a "AssemblyInfoShared.cs" file that contains a common set of assembly-level attributes (AssemblyCompany, AssemblyTrademark, etc) which is added to each project via linked file from a common location outside this solution. This is in addition to the project-specific AssemblyInfo.cs. There are no overlaps between to two files.
Back to top
Remco
#11 Posted : Monday, April 30, 2012 11:19:13 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Thanks. Knowing that the issues are occurring within the scope of a single project helps to rule out a large number of dependency resolution and versioning issues, so this is good news.

I think the best thing to do from here (if you are able to reproduce the problem again) would be to try to identify what NCrunch *thinks* it is seeing in the file(s) that are failing to build. The easiest way to do this is to look into the workspace used by NCrunch for the build of your project, then compare the contents of this workspace with the expected content as shown in your IDE.

So for example, if NCrunch suddenly failed to build UI_Project stating that Control1ViewModel has a problem referencing ViewModelBase, the best plan of action would be to right click the failed project build, choose Advanced->Browse To Workspace, then find the Control1ViewModel.cs and ViewModelBase.cs files in the workspace and compare them with the contents of your IDE windows for both of these source files. It may also be worth using some kind of binary comparison tool against these files as they exist in your original solution on disk, so we can rule out any file encoding or line ending issues (these have been known to cause problems for NCrunch in the past). My current guess is that there is something wrong with the way these files are being loaded up from disk that is somehow causing them to be written back in a corrupt form.

Something else worth checking ... are any of these files in your solution marked with special file attributes on your file system? (i.e. read-only, hidden, system, etc).
Back to top
johnmwright
#12 Posted : Tuesday, May 1, 2012 1:27:56 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
I hadn't noticed the Browse To Workspace menu before -- that will definitely help troubleshoot this issue the next time it occurs.

This project uses TFS for source control, and the Visual Studio integration will mark all files as Read Only on the filesystem until you explicitly set them for edit, so there are a lot of the files marked as Read Only. Since they get put back into Read Only mode once I commit my changes, I'm not sure what state the files were in when this issue was occurring, since I've committed several change sets since then. I will add this to the list of things to look for if it occurs again. I've only been using TFS for a few weeks now, so I'm unfamiliar with the ins-and-outs of how it handles files -- should have mentioned this early.. sorry.
Back to top
Remco
#13 Posted : Tuesday, May 1, 2012 10:43:36 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
That's ok - do let me know if you experience another occurrence of the issue, I have a feeling we're getting close.
Back to top
johnmwright
#14 Posted : Wednesday, May 9, 2012 9:44:16 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
Ok, had another issue today. Not exactly the same issue, though. In this case, NCrunch was complaining that my UI project was failing to build, with messages like this:
' Controls\SomeWizardControl.xaml.cs (34): The name 'CrmAuthentication' does not exist in the current context
' Controls\SomeCodeBehind.cs (86): The name 'CrmAuthentication' does not exist in the current context
' Controls\SomeCodeBehind.cs (112): The name 'CrmAuthentication' does not exist in the current context
' Controls\AnotherWizard.xaml.cs (57): The name 'CrmAuthentication' does not exist in the current context
' ViewModels\ThirdWizardViewModel.cs (55): The name 'CrmAuthentication' does not exist in the current context
' ViewModels\ThirdWizardViewModel.cs (165): The name 'CrmAuthentication' does not exist in the current context
' ViewModels\SomeViewModel.cs (103): The name 'CrmAuthentication' does not exist in the current context
' Extension.cs (295): The name 'CrmAuthentication' does not exist in the current context
' Extension.cs (334): The name 'CrmAuthentication' does not exist in the current context

The project in VS is happy to compile, and ReSharper registers no issues, so I went to Advanced->Browse to workspace and found that the CrmAuthentication.cs file existed, but was completely empty. The file properties shows file size as 3 bytes. Whereas the same file in the solution folder is 16.5KB.

Other notes:
While I have been working in that file today, I had not touched it in some time and I know NCrunch was working since I last touched it, as I demo'd NCrunch to my boss since then :-)

CrmAuthentication.cs is marked as read-only on the filesystem, since this is how TFS handles files that are not checked out for edit. Note, however, that most of the files in the solution are marked as read-only at this time.

Using Beyond Compare, I did a recursive folder comparison between my solution folderand the NCrunch working folder. I found only two differences (aside from the bin folder and build artifacts):
- CrmAuthentication.cs is empty
- the .csproj file has been modified in the NCrunch folder. Aside from the reference changes, etc, to make NCrunch work, I noticed that the first line of the .csproj file changed the xml encoding from "utf-8" in the solution folder to "utf-16" in the NCrunch folder.

Right-clicking on the project in the NCrunch Tests window and selecting Rebuild did not resolve the issue. However, disabling NCrunch and immediately enabling it did.

Unfortunately, I forgot to submit a bug report through VS before doing the disable/enable.
Back to top
Remco
#15 Posted : Wednesday, May 9, 2012 11:49:34 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Hi John,

Nice analysis. The csproj encoding changes are normal, but NCrunch forgetting the content of the source file is definitely not. I have a feeling this is the same issue you described earlier, though affecting a different file. The problem itself will be something in the way that NCrunch is either obtaining the file content from Visual Studio, or from the file system - so don't worry too much about the mechanics of the source code itself since this likely won't make any difference.

Do you remember if the file was open in the IDE when you first experienced the problem? This will help me to narrow down which loader caused the issue.
Back to top
johnmwright
#16 Posted : Thursday, May 10, 2012 1:15:58 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
I know the CrmAuthentication file was closed when I _noticed_ the NCrunch indicator was orange, but it's possible it was open when it actually started to break. I'll keep you posted as I discover more detail.

FYI: I haven't seen the issues I originally reported for a while, even though I've been working heavily in this code for the last couple of weeks.
Back to top
johnmwright
#17 Posted : Thursday, May 10, 2012 2:58:57 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
I was saw one of the issues today and have a better idea of what's happening. Below is what I did. I submitted a bug report from within Visual Studio with the name "NCrunch code out of sync" as soon as this happened.

A little more background:
I have two visual studio solutions open:
1) my project that I've mentioned in this thread
2) the company's SDK solution for our primary product.

My project consumes the SDK binaries via referenced .dlls. The two solutions share a common build output folder (ie: they are both configured to use ../Bin, which resolves to the same physical file folder). As part of my project, I may need to modify the SDK to provide additional functionality that I need to consume in my project. When this happens, I will modify the SDK code, save, then kick off a batch script that builds the SDK code, thus created a new set of .dlls in the ../Bin folder.

For this specific case, here's what happened:
* I started to edit a .cs file in my project, but realized the SDK did not provide exactly what I needed, so I switched over to the SDK Visual Studio instance. At this point, the .cs file I was editing is not in a compilable state (ie: I didn't finish the line I was editing, so it was not syntactically complete). This class extended a base class named ViewBase.
* In the SDK solution, I modified ViewBase and saved the file.
* From a command prompt, I ran the batch file that builds the SDK solution. This solution creates many binaries, of which my project consumes about 6. As the build script progressed, and .dlls were placed into the ../Bin folder, the NCrunch instance in my solution started rebuilding projects, as expected. However, at this point, I believe things got out of sync, likely due to .dlls being updated quickly in the ../Bin folder while NCrunch was kicking off builds at the same time.

The build script for the SDK solution takes about 4 minutes to run on my machine. At the end of the builds, NCrunch showed broken builds in my solution for the project with the incomplete file. However, I then finished editing the file so that it was valid, and even saved and built the solution (successfully). But NCrunch did not register the change, showing a broken build with this message:
' Controls\FileBeingEdited.xaml.cs (30): Identifier expected
' Controls\FileBeingEdited.xaml.cs (30): ; expected

Browsing to the NCrunch workspace for that project indeed showed that the problematic file was stale, showing the incomplete line as it looked before I started the SDK build.

While I don't think this specific scenario caused all of the issues I've seen, as I don't run an SDK build that often, I do pull latest code from TFS roughly daily, which likely touches the files which are currently open in my VS window. If NCrunch gets out of sync when outside processes touch the files, that might be what's happening.

As always, let me know if there is any additional data I can provide.
Back to top
Remco
#18 Posted : Thursday, May 10, 2012 10:04:39 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Based on the description you've just given and some errors found in the log file you just submitted, I have a theory on what's causing this.

Basically, when you run the SDK build script it's holding a read/write lock on the binaries that are being referenced from your working solution. This is causing problems when NCrunch attempts to construct its workspace, as it can't copy the files out due to locking exceptions. Normally NCrunch would just carry on and resolve this issue the next time it tries to synchronise the workspace (i.e. when the SDK build has completed), but the workspacing exception is causing other modified source files to get out of sync between the workspace and your working solution.

Anyway it's just a theory at this stage - but what I'd like to do is include a fix in the next version of NCrunch (due out very soon) and see if this resolves the problem for you?

Cheers,

Remco
Back to top
johnmwright
#19 Posted : Friday, May 18, 2012 4:30:29 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/27/2011(UTC)
Posts: 45
Location: Chicago, IL

Thanks: 3 times
Was thanked: 7 time(s) in 6 post(s)
Update:
I upgraded to v1.39.0.15b, but am still seeing (similar) issues. Below is what I found.

In the NCrunch Tests window, the UI project is showing as 'Build failure' with messages like these:

C:\Users\jwright\AppData\Local\NCrunch\9616\99\MySolutionName\MyProjectName\Controls\AuthenticationDialog.xaml (17)#0: The property 'AutomationIdBehavior.AutomationId' does not exist in XML namespace 'clr-namespace:MyReferencedNamespace;assembly=MyReferencedAssembly'. Line 17 Position 9.

There are five errors, all from .xaml files with references to the same external (not part of this solution) assembly.

In the real .csproj file, I have references defined for that external assembly like this:
. <ItemGroup>
. <!-- ... others removed -->
. <Reference Include="MyReferencedAssembly">
. <HintPath>..\..\Bin\MyReferencedAssembly.dll</HintPath>
. <Private>False</Private>
. </Reference>
. <Reference Include="microsoft.xrm.sdk">
. <HintPath>..\Libs\Dynamics2011SDK\bin\microsoft.xrm.sdk.dll</HintPath>
. </Reference>


In the NCrunch working folder, the .csproj shows the same references like this:
. <ItemGroup>
. <Reference Include="MyReferencedAssembly.dll" />
. <Reference Include="C:\Users\jwright\AppData\Local\NCrunch\9616\99\_ncrunchreferences\microsoft.xrm.sdk.dll" />

Note, however, that the MyReferencedAssembly.dll does not exist anywhere in the NCrunch working folder structure.

In this case, that file that is referenced is actually built by another script on my machine, which I ran around the same time NCrunch started failing. I suspect that the script is doing a clean (thus removing the referenced .dll file), then after building dependant modules (a minute or so later) placing the new instance of the .dll. It is likely that during this period where the .dll is removed that NCrunch attempts to sync folders and fails. Unfortunately, it doesn't seem to register when the file is eventually recreated.

Only after unloading/loading the project does NCrunch go green again.
Back to top
Remco
#20 Posted : Saturday, May 19, 2012 12:12:27 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Hi John,

I think your analysis is correct in that this issue is also being caused by race conditions between the script you're running and NCrunch's workspace construction. Have you noticed any further issues around NCrunch throwing build errors related to source files? Or does it now only seem to affect referenced assemblies?

I'll need to have a bit more of a think about how to further strengthen the error handling in this part of NCrunch. It may be that the correct answer is to simply assume the entire workspace is corrupt and that it should be thrown away in the event of this happening.
Back to top
Users browsing this topic
Guest
2 Pages12>
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.179 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download