Search

MSLinqToSQLGenerator fails with partial class having a Using at the top of the file by gman

Closed
as Fixed Help for as Fixed

71
0
Sign in
 to vote
Type: Bug
ID: 361577
Opened: 8/12/2008 8:54:46 PM
Access Restriction: Public
4
Workaround(s)
81
User(s) can reproduce this bug
This error began to occur with SP1 of Visual Studio 2008.

If you add a partial class declaration to a Linq-To-SQL Data Classes context object, and then put a "using" statement at the top of the file outside the namespace declaration, the following error occurs when you run the custom tool:

"The custom tool 'MSLinqToSQLGenerator' failed. Unspecified error"

Also, Visual Studio will then delete the corresponding ".designer.cs" file for your data context and nothing will compile after that point.

Now, the workaround is to move my "using" statements INSIDE the namespace declaration - and then it works!
Details (expand)
Product Language
English

Version

Visual Studio 2008 Service Pack 1
Operating System
Windows Vista
Operating System Language
English
Steps to Reproduce
1. Create a new project

2. Add a new "Linq to SQL Classes"

3. Highlight the .dbml file and press F7 to add a partial class and bring it up in the editor

4. In the partial class, add "using System;" as the first line in the file

5. Save all, right click the DBML, and select "Run Custom Tool"

6. Witness the error
Actual Results
Error message is generated: "The custom tool 'MSLinqToSQLGenerator' failed. Unspecified error"
Expected Results
No error. Generation should work.
TAP Code (if applicable)
 
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey. [Details]

 

File Attachments
0 attachments
Sign in to post a comment.
Posted by Qwertie on 1/31/2012 at 3:18 PM
I ran into this bug today... I never would have guessed that the 'MSLinqToSQLGenerator' would open my custom code file AT ALL, let alone crash if it contains "using" statements at the top.

I'm still on VS2008, which is my default IDE since MS dropped WinCE support in VS2010.
Posted by Ken Eucker on 8/16/2011 at 12:03 PM
Going on three years and this still isn't working. Win7 x64 VS2010 ASP.NET web application.
Posted by HoboZero on 6/28/2010 at 11:07 PM
I also would like someone to take a second to tell when this fix will be applied. It has consequences in how we approach our design!
Posted by Doug Clutter on 2/7/2010 at 8:27 AM
Moving the usings worked for me too! Thanks for posting the work-around, but I agree with the other posters. Having a work-around is NOT the same as tagging this issue as "Closed" and fixed. If it's been fixed in VS2010, then please just say so.
Posted by JesseJ on 12/21/2009 at 3:43 PM
Microsoft: Please open this case back up or print how we can fix our machines besides the workaround...

-JD
Posted by flintoff on 11/23/2009 at 8:18 AM
If this is "fixed" how can I fix my version of vstudio? Or is the fix to upgrade to 2010?!
I've just lost an hour finding this - for me my designer file magically dissappeared out of my project (but luckily not my source). SDidnt get the error on save or build - you only get that if yiou say run custom tool.
Not exactly easy to find this, even with the help of google (or bing..)
Posted by jrummell on 9/8/2009 at 4:39 PM
Is there a patch available with this fix?
Posted by Roman Rozinov on 6/16/2009 at 4:43 PM
I am not sure I understand why this was just closed. Is there a timeline when this will be fixed? It's clearly a bug and the one that wasted half of my day b/c VS kept regenerating the designer.cs but then it would be destroyed with the error message above. I'd like to keep this open until it's been fixed.
Posted by y2k4life on 1/12/2009 at 10:37 PM
I noticed this might not possible go into the next release.
Does this mean we have to wait for VS2010?

Here is my arguments for making a HotFix.

1. the easy in which it is reprodusable.
2. Caused by a mundan code change.
3. Breaks by means that no other things break like. (first time to see a Using being in the wrong place and causes a problem).
4. if one does not find the fix/work around it causes frustration.
5. Possibility of lost code *.designer.cs get removed and never comes back unless the *.dmbl is deleted.
6. Plus the lose for productivity this causes (I myself have lost about 1 hour).

Another work around to mitigate the impact when you VS decides to delte the *.design.cs files is to make multiple .dbml files. If one breaks you don't loose everything you just have to rebuild the ones you loose.

Why does this BUG not warrent a HotFix? For something as simple as this would it not be done just for PR. Save face?
As much as I love MS. I like to demo to people how I can make MS products blow up in three easy step.

I guess I can add this to the list and show people this until I guess what VS 2010 comes out? We have to wait that long?
Posted by y2k4life on 1/12/2009 at 10:27 PM
I don't want to cross post. Plus the editor for MS Connect is not as powerfull. There is some user feed back for making MS Connect better. Make this an editor 2.0+. I like the ability to wrap code.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4290943&SiteID=1&mode=1
Posted by Microsoft on 10/27/2008 at 2:22 PM
Thank you for your feedback. We’ll look into this issue for a later release.

If you have any other feedback or concerns, please let us know.

Thank you
Data Programmability Tools Team
Posted by hmadrigal on 9/25/2008 at 10:09 AM
I had the same issue, but in my case I have to remove everything before the 'namespace' keyword. It means that I had to remove the directives such as #define and the using keywords.
Posted by Victor Gladkikh on 8/14/2008 at 8:30 AM
This is very scary error... I think I become older by ten years...
Posted by Microsoft on 8/14/2008 at 12:17 AM
Thanks for your feedback. We are escalating this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Sign in to post a workaround.
Posted by Giedrius Banaitis on 8/13/2008 at 6:43 AM
looks like i found workaround - in partial class you need to move using statements within namespace, let's say you had:

using System.Data.Linq;
using System;

namespace XXX.DataAccess
{
....
}

you need to make it like:

namespace XXX.DataAccess
{
using System.Data.Linq;
using System;

....
}

don't ask me why it is so and how i've found this :)
Posted by Mohammad Porooshani on 8/19/2008 at 11:18 PM
Adding to the first submitted workaround;
If by any (I think very high) possibility Visual Studio deleted your .designer file, it may refuse to compile even after moving using statements inside namespace block, then you should right click over .dbml file and select "Run Custom Tool" to make .designer again.
After that you should have your project compiled.
Posted by mkamoski 1 on 8/11/2009 at 7:19 AM
I just got this error for the 1st time today-- The custom tool 'MSLinqToSQLGenerator' failed. Unspecified error -- My machine and software is fully patched. This issue seemed to only occur on the file that created "under" the "DataClasses.dbml" file in the Project Explorer, the file that is generated by the Designer when one points to the Context Design Surface and one right-clicks and chooses "View Code", then THAT partial class physical file must not have ANYTHING at all before its "namespace" line, not even blank lines. However, I did discover that if I make an other physical file somewhere else (not "under" the "DataClasses.dbml" file), and that other file IS an partial class for the same Context then that other file CAN have stuff before the "namespace" line, such as "using" statements. As such, this is, IMHO, my guess is that this is probably an issue with the Run Custom Tool code generation engine, probably T4-related. HTH. Thank you. -- Mark Kamoski
Posted by Andrey Tagaev on 1/9/2010 at 3:50 AM
The submitted workaround is works!
Moving using clauses inside the Namespace really helped!

Thanks!
© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement