I will be releasing an XNA Game Library beta in DLL form soon and I would like to provide setup instructions. I need to know how tp add a DLL file so when the game is built in Release config and taken to another computer with .NET and XNA, the dll is still included and can be used by the built game. In other words I want the dll to go with the game binary, but not be directly built into the exe itself. How can this be done?

As much as I hate to bump this I think its unfair that mine was the only thread that died without reply.

There's nothing unfair about it, no offense. These are forums where people come to talk and help each other *on their own free time*. No one gets paid for answering my questions, and I don't get paid to answer yours. But you can pay me if you like! :) Many of us have jobs, families and real life things to deal with. So if you wait a while, someone will get to you eventually if your question isn't something silly. Check out my thread I posted today called "[SlimDX] Factory1 constructor fails". I only got one answer, and had to resolve the problem myself. But I don't call it unfair. People were either busy or just didn't know.

But your question seems a bit strange to me, which may be why no one replied yet. What exactly are you talking about? When you build your project, it will output the DLL to your output directory. If your solution consists of an executable game and the DLL, then you will get both in the output directory, unless you un-check "Copy Local" and set the DLL project settings to be output elsewhere. Users simply have to put the game and DLL together in any folder (and of course, have XNA installed). Visual Studio does not merge .NET DLLs into executables. AFAIK, the only way to merge .NET assemblies is to use a post-build tool or something like ILMerge (or write your own tool or self-extracting exe logic).

So the answer to your question: Click "Build". :)

Sorry about my fail bump, I was angry then. As for my issue, I solved it. What I wanted was instructions on how to add an external downloaded DLL to a game project so when the game was built or published, the DLL would follow so the the customer/player wouldn't have to download it himself. My solution, right click the project in solution explorer and add the DLL directly into the project. I built a test game and looked in the Debug folder and found that it was included and saparate from the game itself. Again, sorry about my bump. It just seemed to me that since the old creators.xna.com gave me a quick response (until Microsoft took it and kicked me out), I thought this site would be near instant.

[Edited by - Drakken255 on October 24, 2010 1:43:44 AM]

It's ok. Glad you are comfortable with your project build now. I might have bumped my own post if I had a big problem. My point was just take it easy on the folks here, since we all help each other out of kindness, not for money, favors or to get our federal weapons trafficking and racketeering charges dropped by the ATF and FBI. But COULD someone help me with that last bit!? Lol, kidding. Darn RICO Statute! :)

But I'd like to reiterate what I said about building your project. If you reference your DLL in your game, by default, Visual Studio (or VC#) is going to copy it to the output directory. So there you will find, for example:

"mygame.exe" and "mylib.dll"

That's the DEFAULT. I'm not sure why you would add it into the solution directory itself, unless you mean the DLL project (and source), and not the binary (*.dll file). Because if you just added it into the solution directory, it's not even referenced unless you clicked "Add Reference" and browsed to the DLL file and added the reference. My suggestion is find a convenient location that's easy for you to find, then stick the DLL in there. Then you browse to that folder and reference it when you want to use it; don't "add" it INTO the project, which accomplishes nothing. Then anytime you click "Build", the DLL will accompany your game, and appear right next to it in the bin\...whatever folder. Distribution is as simple as giving users the game and dll; ideally in an installer or a Zip/RAR archive.

Alternatively, you could write an installer that adds the DLL to the GAC. Then any .NET assembly can consume the DLL from anywhere. That's exactly how you can use things like System.dll or Microsoft.Xna.Framework.dll without them being in the same folder as your game. But don't do that unless you have a VERY good reason to. Users may not like it either. I've only been compelled to do that once with an application framework I wrote, because it's consumed by a large number of executables and other libraries.

Lastly, Visual Studio (or VC#) will NEVER "merge" a DLL into a program (executable) or another library (dll). That simply does not happen. So I have no idea where you got that idea. :) The only thing similar to that, afaik, is when you build a static .LIB in C/C++ or some other native language. The linker links the static LIB into modules/assemblies which depend on it. But this is something you NEVER have to worry about happening with a DLL (especially a .NET assembly).

EDIT:

Just out of curiosity, please tell me about this. What are you planning on publishing, and what is this DLL you're talking about?

You don't have to add the DLL to the project? Ok I just recall someone else having the inclusion problem. I'll re-work my instructions. Anyway, the DLL is a game library for XNA that I am building. It is intended to have a variety of uses, but the main feature right now is my Word Processor Beta. For example, notice there's nothing in the XNA library that gives you login fields or chat boxes. You have to use GamerServices.Guide.BeginShowKeyboardInput(). This is what my beta does. And as much looking I have done (because I once needed it), no other exists. It's almost done; I will be releasing it later today, so watch sclwordprocessorbeta.codeplex.com and try it for yourself!

No, the DLL does not have to be put inside of the project/solution directory. I'm assuming you're talking about a compiled (binary form/object code) *.dll file, and NOT the DLL project (the source code) itself. All you need do (in your game project) is click "Add Reference", then go the the "Browse" tab, find your DLL, and reference it.

If you don't REFERENCE the DLL, then you aren't even using it. An assembly doesn't know how to magically use something it doesn't reference (and I'm sure you know that). Once you add the reference, you should see it in the list in the "References" folder, along side System.DLL, Microsoft.XNA.Framework.dll and any other assemblies you're referencing. If you click on the icon of a referenced assembly in the list, you will see properties/setting in the "Properties" window below. One of the options you will see there is "Copy Local" (a flag which can be set to True or False). By default, any assemblies residing in the GAC (Global Assembly Cache) or that have been registered (like System.DLL and any Microsoft.XNA dlls) have this flag set to False. The reason is because the Windows PE loader knows where to find them: in the GAC. But 3rd party DLLs (like YOURS) that have not been registered must be in the same folder (or have an embedded manifest which gives their location; see MSDN for details) as any executables which depend on them. If you click on YOUR DLL's icon, you will notice that "Copy Local" is set TRUE; Visual Studio is smart enough to know that your game will need the DLL to be next to it in the same folder to run. That's how it all works by default. And the C# compiler/linker will NEVER "merge" a DLL into anything else. They will always be output as their respective executable modules (DLL/EXE) in the output folder.

Have you already built this DLL and are trying to use it from your XNA game project? If you're developing both at the same time, why don't you just have a solution with BOTH projects in it. Then you can reference the DLL project itself, and it will automatically parse your XML documentation/comments. Then when it's time to build, everything is taken care of for you. There's no need to have two solutions: one for the game and one for the DLL. It's much easier to work with them together if you aren't doing that already.

The reason there's no text/login/chat boxes in XNA is because that's not what XNA is for. :) Every team/company wants to make their own awesome, creative and original GUI for their game anyway. There are some samples online for XNA, and the DirectX SDK has a sample with GUI/textboxes. Maybe that'll be worth taking a look at. The DX SDK sample is VERY nice.

Ok, thanks for clarifying. My DLL is a binary, so this helps a lot for my instructions. As for the reason behind my DLL, it's intended to have many uses, but I decided to build in a text input GUI so people that don't have the experience to go DirectX (me) and can't make it in XNA can still have the ability to use such features. And I'm building it with the ability to customize each individual text box, as well. Once I get the multi-line boxes running, I will also add customization for the scroll bar. The whole point in the text input portion is the ability to easily access it while still making it blend well with the programmer's game. So, that being said, thanks for your help and please try it; I'd like some feedback such as yours for improvement.

Ok, I didn't have time to actually write an XNA game project and see it in action. But I did reference the assembly to see what's in it and what the public interface looks like. And I notice some things which could definitely use some changes. So let me make some suggestions to you.

Firstly, publishing a DLL with spaces in its name isn't the best idea AFAIK. Look in the GAC or WinSxS directory, and none of them have spaces. You also should have changed the default namespace. Currently it's: Smart_Cookie_Game_Library (VC# Express adds the underscores if the project name has spaces and you don't specify a new default namespace). That's quite unwieldy, and doesn't make for the prettiest code. Why can't the default namespace be "SCGLib"? or something short and easy to type? That's just an cosmetic concern.

Secondly, what's up with the "MathForumulas" class? It only offers 3 static methods. You should automatically get rid of the two "GetDistance" methods. Xna already provides them (Vector3.Distance(...) and Vector2.Distance(...)). So then that's a class with one static method. So I don't really see the justification of this class even existing. Stick the "ConvertToBoundingBox" method somewhere else, or add some useful "beef" to that class so it's useful. Personally, I just say get rid of it. The next problem with this class is that it has ONLY static members, yet it's perfectly fine to instantiate it? This is perfectly legal with your library:

MathFormulas m = new MathFormulas();

Why? There are absolutely no instance members! :) You should have at least marked the class static. But again, I think it's overkill. Just get rid of it.

Next, I looked at the "WordProcessor" class, and wanted to get a feel of how it might work and what the code might look like to use it. It wasn't very pleasing, mainly due to this monster:

WordProcessing.WordProcessor wp = new WordProcessor(null, null);
wp.AddTextBox(null, TextBoxType.BoxLimited, TextBoxBorder.Normal,
Color.Firebrick, Color.Firebrick, 0, 0, 0,
false, false, false, false, false, false,
false, Vector2.Zero);

Rarely are that many parameters justified in doing something so simple. This looks like a mistake I made when I first started programming. I was always worried people were going to "steal" my code or ideas, and my paranoia made me make some unwise design choices. For instance, I used to treat visibility modifiers (keywords like private, public, internal, protected) as some sort of "security" feature. i.e., I'd mark something private or internal because I thought it was some highly prized, awesome code I didn't want anyone to know about and hijack, lol. Mind you, I was just a kid and my code was so crappy I'm sure NO ONE wanted to steal it from me. ;) But something tell's me there is some sort of class for a "textbox" in there that's marked internal so people can't use it. I'm not sure, and not saying that's why you did it if there is such a class, but then why this huge method just to "AddTextBox"? Why can't there be a public "TextBox" class which one can instantiate (providing both small and complex constructors and having default values for fields) and then pass to the WordProcessor class? Something like:

TextBox textBox = new TextBox(<some style parameters could go here>);
myWordProcessor.AddTextBox(textBox);

Which one would you rather use? The intuitive, less-typing version? Or the big "wrapped up" version where client code can't use a "TextBox" class and has to type a million parameters? I can only guess that the trouble you went through to design it this way forced you to write some nasty code inside of "WordProcessor".

That's about all I've had time to look at so far. I'd also like to mention that the library itself is TINY! Honestly, I would never use a 3rd party DLL that only offered one or two small classes unless it did something crazily complicated that I didn't want to do or was some revolutionary piece of work. I see you also didn't release the source for the DLL. My heartfelt suggestion is that you DO release your source and try to get other people involved and get some help (then you might be able to make a big utility library lots of folks would be interested in). Working with and associating with other programmers can greatly increase your skill and efficiency; and I don't care how good of a programmer you already are! Don't be afraid to release source because you think someone will "steal" it. If someone really wants to, they'll just decompile your code. But the truth is, I've NEVER heard of someone getting their code "stolen". It sucks bad enough just to read another person's code that you're working with, much less try to reverse-engineer and "steal" code, haha. Maybe you already know this, but I'm just saying it aloud.

Hope you don't mind my (sometimes brutal) honesty, but I feel that criticism makes better programmers and better programmers make better code. If you want more help or opinions on this, you know where to find me. Feel free to pm. I've got a very big project going on (an application framework, SlimDX/DX11 engine and a naval battle demo; plus my day job programming), so I might be slow to respond. But I'll do whatever I can if you want further assistance.

Nah, I appreciate every bit of criticism, no matter how harsh, a long as it's not like, "u stoopid mother effin n00b! U dunno wut u doin!" Ok, first, the MathFormulas was originally for me because I had a project in which I would get the distance a lot and I didn't know the Vector classes had those functions. And the ConvertToBoundingBox was so my 2D project could use circle-like intersection, but now I see the pointlessness. The ability to instantiate it? To be honest, I'm not that good at programming yet, so I missed that, but I make up for my lack of skills by, when presented with a problem an experienced person could solve, I can find workarounds that seem to not be there and actually work. So, let's scrap the math class. Next, the reason I worry about stealing is because this word processor is the only one of it's kind, and what would someone do to get in on the credit? They could write their own version, or steal mine, but if you don't believe this will happen, I'll take your word for it; you've helped me greatly so far.

Long name? Done. I thought it was annoying too. And the library is supposed to have a large amount of small or decent size functions. I just haven't found and made them yet.

As for the AddTextBox method, that's what gives each text box its individual customizability. I do agree that it is long, and I was looking into theme-based creation, where I have a TextBoxTheme struct that the user can use to call AddTextBox with, only passing the theme and the position. The reason I kept (and you were only two capitalizations off) the TextBox class internal is because I didn't know if, by creating a TextBox directly in the game class would cause a malfunction in my or the user's classes. And I didn't want stupid complaints littering my site based on something THEY did that broke their game. It might not, I don't know (GOD I wish I had a computer science class in my school).

Any way, I will make the source code available. And for your immense help, would you like to become a contributor to the library project? I won't require much time from you aside from a few suggestions here and there. Mostly it's credit I'm giving you for helping.

[Edited by - Drakken255 on October 26, 2010 10:56:37 AM]