tguillor
asked on
Does source code make sense?
I was given the task of "fixing" a C# Windows application. The application runs in our shop, but the source code is kept at our headquarters, in a land far, far away. In a lapse of propriety, I'll say that their source control is atrocious. Most of the time, they can't find source code, much less know if it's current.
For background info, they used an earlier version of C#. The Framework is 1.xxx (can't remember exactly which). We are using VS2005, Framework is 2.
When I opened the solution, it asked me if I wanted to upgrade. I said yes. So far, all appeared normal. When I tried to build the resulting solution, I had 32 errors. I resolved all but one of them in short order, by adding using statements and relatively easy things like that.
The last error, and the one that I saved for Monday, is detailed below. I'm afraid my C# skills are not yet good enough to know if this is allowed.
The last error says that (we'll call it) ReportBuilder is declared twice in the same namespace. There is a public class named ReportBuilder and a public method in that class named ReportBuilder. Is that legal? What's the answer to that?
But the more important question is, do you think this source code is what we are actually using in our compiled app? Would the conversion from an older C# version to the latest version cause so many namespace errors? I mean, these were .NET Framework namespaces, like System.Data, routine stuff like that. Would the conversion process cause 31 of these things to be lost?
I know you can only speculate without seeing the code, but it sure makes me uneasy to have code that doesn't compile, and most of it for fairly trivial reasons.
Please give me your opinions.
For background info, they used an earlier version of C#. The Framework is 1.xxx (can't remember exactly which). We are using VS2005, Framework is 2.
When I opened the solution, it asked me if I wanted to upgrade. I said yes. So far, all appeared normal. When I tried to build the resulting solution, I had 32 errors. I resolved all but one of them in short order, by adding using statements and relatively easy things like that.
The last error, and the one that I saved for Monday, is detailed below. I'm afraid my C# skills are not yet good enough to know if this is allowed.
The last error says that (we'll call it) ReportBuilder is declared twice in the same namespace. There is a public class named ReportBuilder and a public method in that class named ReportBuilder. Is that legal? What's the answer to that?
But the more important question is, do you think this source code is what we are actually using in our compiled app? Would the conversion from an older C# version to the latest version cause so many namespace errors? I mean, these were .NET Framework namespaces, like System.Data, routine stuff like that. Would the conversion process cause 31 of these things to be lost?
I know you can only speculate without seeing the code, but it sure makes me uneasy to have code that doesn't compile, and most of it for fairly trivial reasons.
Please give me your opinions.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
As an inheritor of countless Delphi scripts that still make very little sense to me, I can certainly understand where you're coming from.
Let me know if you still need any help after testing this on Monday.
Let me know if you still need any help after testing this on Monday.
ASKER
Pretty intricate stuff the guy wrote, Web Services, delegates, he was really using what he learned in school :-) And not the first comment anywhere in his code. Last time I inherited some of his code, once I understood the business reason, I replaced a huge bloated app with eight lines of VBScript that performed the same functionality. Added bonus: it even worked :-)