Just installed the new version, and had a very smooth migration. Everything worked 100% out of the box.

However, even though the newly generated code compiles, I am getting the following compiler warnings (one for each .cs file):

"The custom tool 'LLBLGen Pro' failed while processing the file 'foo.cs'."

I believe the warning is caused by this line in the project file:

                <File
                    RelPath = "DatabaseGeneric\AssemblyInfo.cs"
                    BuildAction = "Compile"
                    Generator = "LLBLGen Pro" <!--this is the line-->
                />

For some reason, these warnings only show up in VS.Net--when I run my automated build script, there are no compiler warnings.

What am I doing wrong?

When do they show up, when you load the project file?

And are you using VB.NET? I don't get the warnings in C# and vs.net...

Otis wrote:

When do they show up, when you load the project file?

And are you using VB.NET? I don't get the warnings in C# and vs.net...

Yes, they show up when I load the project. I guess they aren't compiler warnings after all.

I'm using C#. It must have something to do with my machine's setup?

More info:

If I double click any of the warnings, I get a popup that asks if I want to re-run the custom tool. When I say yes, the error changes to:

"Cannot find custom tool 'LLBLGen Pro' on this system."

I can then right-click and go to a help topic entitled:

"CustomTool Property (Visual Basic and C# ProjectItem Object)"

However, I still have no idea what one thing has to do with the other.

Ah, I see them now too.

Hmmm. I use that 'Generator' tag to store information for the project file task performer so it knows which files are generated and which ones aren't, so when you switch on the setting to clean the project file it knows which files to remove.

As 'Generator' is a known attribute, it leaves the value, otherwise it removes it, so I have to use that one... It's completely harmless btw. You can ignore it.

I'll see if I can find another way to store the info...

Otis wrote:

Ah, I see them now too.

Hmmm. I use that 'Generator' tag to store information for the project file task performer so it knows which files are generated and which ones aren't, so when you switch on the setting to clean the project file it knows which files to remove.

As 'Generator' is a known attribute, it leaves the value, otherwise it removes it, so I have to use that one... It's completely harmless btw. You can ignore it.

I'll see if I can find another way to store the info...

Yep, it caused no actual problems, and doesn't show up in my automated build, just in VS.net.

That generator tag only shows up when you generate over an existing project file, BTW.

Otis wrote:

As 'Generator' is a known attribute, it leaves the value, otherwise it removes it, so I have to use that one... It's completely harmless btw. You can ignore it.

What removes unknown attributes? VS.Net?

I tried find/replace on the project file from "Generator" to "Blah", and the problem went away on re-opening VS.Net. When I re-opened the project files, the "Blah" attribute was still there.

I didn't test this extensively, though, so don't trust my word.

I'm hoping you come up with a solution for this, because the "clean project file" feature will make my job much easier.

Cheers,

Phil

Try saving the project again . The attributes which don't belong to the vs.net project are removed as they're not stored inside the project.

Otis wrote:

Try saving the project again . The attributes which don't belong to the vs.net project are removed as they're not stored inside the project.

Yep, gone.

psandler wrote:

Otis wrote:

Try saving the project again . The attributes which don't belong to the vs.net project are removed as they're not stored inside the project.

Yep, gone.

Sad isn't it. . I even installed the VSIP sdk to see if I could find a schema of the file, so I could choose which attribute to take.

I've to think this through if this gives problems or not. It's more or less trial/error which attributes there are and what effect they might have...

I was looking for documentation on why this happens yesterday, and couldn't find anything. Where do you get the schema?

I personally wouldn't care if the generator removed ALL files from the project before generating, but we use the generated project as-is, and keep any derived classes in a separate assembly. I'm sure most people don't handle it the same way.

psandler wrote:

I was looking for documentation on why this happens yesterday, and couldn't find anything. Where do you get the schema?

I don't know, it's undocumented, there is no schema defined, anywhere . So with trial/error I found some of the attributes. (the Generator attribute I found after adding a dataset )

Ignore my post, I figured out what was wrong.

Which post? and what was wrong?

Please even if it was a simple problem, giving your feedback about what you faced, may help others who are facing / will face the same problem.

Thanks.

I'm kind of hoping to resurrect this thread...

Any chance more work has gone into solving this? Or that it could?

We have 350 of these warnings and I believe it does (slightly) impact the performance of the IDE while we're running - plus it's just a pain to have to mentally filter them out...

thoughts?

Many thanks in avance...

Randall

jackscoldsweat wrote:

I'm kind of hoping to resurrect this thread...

Any chance more work has gone into solving this? Or that it could?

We have 350 of these warnings and I believe it does (slightly) impact the performance of the IDE while we're running - plus it's just a pain to have to mentally filter them out...

thoughts?

Many thanks in avance...

Randall

Have you upgraded to a newer version of llblgen pro lately? Because this should be fixed by now. It could be the task performer doesnt' clean up the project file correctly because the tags are wrong, so if you have no custom CLASSES in your generated code project, please set the project property under task performers which controls project file clean up to true and re-generate code.

Ahhh.. I did a little searching and I see that the very latest version does solve this... so my next question would be...

I'm currently using 1.0.2004.2 (August 5). If the newest version of LLBL (2005) uses Generics and we have approx 150 Entities (i.e. not including Collections, Lists and Views) how much of a headache is it going to be to switch to n.2005.n and regenerate all our entities. i.e. how much is going to break?

And if the answer is "quite a bit" is there any chance a patch could be done for 2004 (or already exists) that deals with the issue? We have been using 2004 for sometime and it works great for us... we're late in our project and I'm nervous about switching to 2005 if it's gonna break a lot of stuff...

many thanks for your time...

Randall

jackscoldsweat wrote:

Ahhh.. I did a little searching and I see that the very latest version does solve this... so my next question would be...

I'm currently using 1.0.2004.2 (August 5). If the newest version of LLBL (2005) uses Generics and we have approx 150 Entities (i.e. not including Collections, Lists and Views) how much of a headache is it going to be to switch to n.2005.n and regenerate all our entities. i.e. how much is going to break?

1.0.2005.1 doesn't use generics, v2 will use generics. Migration from 2004.2 to 2005.1 is painless, with a little change here and there in custom templates if you have any. Migration from 2005.1 to v2 (when it's released) should be painless as well, as a lot of work has been done to BOTH keep backwards compatibility and have generics.

And if the answer is "quite a bit" is there any chance a patch could be done for 2004 (or already exists) that deals with the issue? We have been using 2004 for sometime and it works great for us... we're late in our project and I'm nervous about switching to 2005 if it's gonna break a lot of stuff... many thanks for your time... Randall

What you can do is this: - install 2005.1 on another system, load your project (create a copy then load that copy), generate code into a new folder. - compile that generated code with the new runtimes, - compile your project with that generated code assembly and the newer runtimes. 10 to 1 it works without a problem.

Many thanks. Will give this a go. Much appreciated!

Prompt and reliable as always ;o)

Right, as always, Otis! Thanks. We've gone from 456 warnings to 58... and all we needed to do was persuade Visual Studio to check it's references...

Many thanks...