C# alias
-
It's not possible I'm afraid. You could always create a snippet with these defined and drag them in when you need them. Cancel my answer. PIEBALDconsult is a coding god here - go with what he said.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
Sure it is. Perhaps not advisable, and not a good fit in this situation, but possible.
-
Hi there I'm just beginning to get my head around C#, having moved from a background in C/C++, Java, and (a long time ago) Pascal. I'm writing a program in which I have declared a series of classes that model the data layer and which, as in this layer I'm working with .xml, the class names reflect the schema of that layer, with names like
...Nodeand...ChildNodeand the like. As I now move up to the business model layer, I'd like to recast these type names to others more suitable to that model. For example, instead of XMLProjectNode I'd like to just use Project. I'm experimenting with aliases and using things like:using Project = My.Namespace.XMLProjectNode;
but what I'd like to be able to do is declare these aliases somewhere in a once-for-all location so that they can be imported into any module for immediate use without the need for redefinition. In C++ I would put some #defines in a header file and #include it wherever I needed them. However, I can't seem to find an analogous way to do that in C#. Am I missing something, or is this not possible? Many thanks BS
You can pass your C# code through the "C-preprocessor", there's nothing stopping you, but I wouldn't recommend that in this case. Have you considered
class Project : My.Namespace.XMLProjectNode {}? That would point up that perhaps your classes like ...Node should perhaps be abstract. -
Sure it is. Perhaps not advisable, and not a good fit in this situation, but possible.
Please expand. Based on my reading of the OP, he was asking if it was possible to store using statements in one location and then reuse them in other locations just by referring to this single location.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
Please expand. Based on my reading of the OP, he was asking if it was possible to store using statements in one location and then reuse them in other locations just by referring to this single location.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
Of course, just as in C like he asked:
C:\>type test.h
using System ;C:\>type test.cs
include "test.h"
namespace Template
{
public static class Template
{
[STAThreadAttribute()]
public static void
Main
(
)
{
Console.WriteLine ( "It works" ) ;
}
}
}C:\>"C:\Program files\mingw\bin\cpp" -P -C -w test.cs test.csi
C:\>csc test.csi
Microsoft (R) Visual C# 2008 Compiler version 3.5.30729.1
for Microsoft (R) .NET Framework version 3.5
Copyright (C) Microsoft Corporation. All rights reserved.C:\>test
It worksC:\>
:-D
-
Of course, just as in C like he asked:
C:\>type test.h
using System ;C:\>type test.cs
include "test.h"
namespace Template
{
public static class Template
{
[STAThreadAttribute()]
public static void
Main
(
)
{
Console.WriteLine ( "It works" ) ;
}
}
}C:\>"C:\Program files\mingw\bin\cpp" -P -C -w test.cs test.csi
C:\>csc test.csi
Microsoft (R) Visual C# 2008 Compiler version 3.5.30729.1
for Microsoft (R) .NET Framework version 3.5
Copyright (C) Microsoft Corporation. All rights reserved.C:\>test
It worksC:\>
:-D
Well blow me sideways with a plastic marionette. I've just learned something new - and if I could award you a 100 for that post I would. Way to go you keyboard lovegod you.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
Of course, just as in C like he asked:
C:\>type test.h
using System ;C:\>type test.cs
include "test.h"
namespace Template
{
public static class Template
{
[STAThreadAttribute()]
public static void
Main
(
)
{
Console.WriteLine ( "It works" ) ;
}
}
}C:\>"C:\Program files\mingw\bin\cpp" -P -C -w test.cs test.csi
C:\>csc test.csi
Microsoft (R) Visual C# 2008 Compiler version 3.5.30729.1
for Microsoft (R) .NET Framework version 3.5
Copyright (C) Microsoft Corporation. All rights reserved.C:\>test
It worksC:\>
:-D
-
Great answer. :D Only caveat would be with
#definesand#if/#else. Since C# DOES recognize those, the cpp preprocessor might be problematic if you used them for any reason (i.e.#if DEBUG blah)Yes, but I have ways of dealing with them. Actually, I only use it for
# defines, it goes back to my PRO*C days. -
Well blow me sideways with a plastic marionette. I've just learned something new - and if I could award you a 100 for that post I would. Way to go you keyboard lovegod you.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
:laugh: I will quote you on that. Once I stop laughing. Which may be a while.
-
Well blow me sideways with a plastic marionette. I've just learned something new - and if I could award you a 100 for that post I would. Way to go you keyboard lovegod you.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
I just wonder if he's willing to be a reference.
-
Yes, but I have ways of dealing with them. Actually, I only use it for
# defines, it goes back to my PRO*C days. -
Yes, but generally just constants like:
# define MAXNAMELEN 32I kinda wish there were a different directive for macroes. It would also be good if the pre-processor took a switch to indicate it should only process the# defines and not other directives. -
Or maybe I misunderstood. My technique for having the C-preprocessor process only
# defines goes back to my PRO*C days. But, yes, I do (kinda/sorta) use macroes in my C# code... just to prove the point. But only when using CSC; I haven't bothered to try to use them with Visual Studio. Even though Microsoft gives good reasons for frowning on macroes in C#, I believe a bigger factor was integration with VS, and I don't fault them on that. -
I just wonder if he's willing to be a reference.
-
I sounds like he's willing to be the father of your offspring!
___________________________________________ .\\axxx (That's an 'M')
Nope. One set of anklebiters is enough for anybody.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
Nope. One set of anklebiters is enough for anybody.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
Or maybe I misunderstood. My technique for having the C-preprocessor process only
# defines goes back to my PRO*C days. But, yes, I do (kinda/sorta) use macroes in my C# code... just to prove the point. But only when using CSC; I haven't bothered to try to use them with Visual Studio. Even though Microsoft gives good reasons for frowning on macroes in C#, I believe a bigger factor was integration with VS, and I don't fault them on that.Thanks for your responses guys, and just to say that I have managed to adapt PIEBALDconsult's creative solution into something that will work in a straight-through build run with MSBuild rather than Csc. I can now run VS Projects and have MSBuild selectively pre-process files that have #includes in them, and process the others normally in one run. The 'trick', if you like, was to set up a custom Task that does the preprocessing if it finds a file with a given extension (and I've used PIEBALD's .csi). All the code is actually written in .cs files, but the build is looking for .csi's in specified cases, and the custom Task is doing the pre-processing and generating these 'pre-build'. All I have to do is link my Task into the project in the 'BeforeBuild' targets:
<Project ... >
...
<Target Name="BeforeBuild">
<PreProcessor
Sender="$(RootNamespace).$(AssemblyName)"
Sources="@(Compile)"
/>
</Target>
<UsingTask Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "
TaskName="PreProcessor"
AssemblyFile="bin\Debug\Com.Cinsault.PreProcessor.dll"
/>
<UsingTask Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "
TaskName="PreProcessor"
AssemblyFile="bin\Release\Com.Cinsault.PreProcessor.dll"
/>
</Target>
</Project>and the pre-processing of the headers is done before the build starts. I suppose there are just a couple of issues though. The most inconvenient is that, as the coding is done in the .cs file, but the build is working off the intermediate file, then any errors or warnings in VS are pointing to the wrong one, and the line numbers will be out too because of the included header code. The other is that, on the first run, MSBuild must find something for the files that it expects, even if these are empty, otherwise - even though the pre-build Task gets to do it's stuff first - MSBuild is looking ahead and saying "I got nothing to work with here!" Could be useful though, so thanks again. BS