yeah i think ill just make my own kinda console on a seperate class / dll (ill have more room to grow and do other stuff with it like you said..besides games like tfc definitly dont use a standard C++ console lol)
thanks alot eric for the info..
I am facing some difficulties with the licensing scheme in .NET.
I have created a solution with 2 projects:
- a licensed windows form .NET control (written in C#)
- a small application hosting the control (written in VB)
Currently, I just try a basic licensing using the .NET LicFileLicenseProvider.
I am quite sure to have written the code as indicated in the .NET doc.
However it does not work. The license exception is raised except is the license file is placed in the application exe directory. It seems that no license key has been embed in the .exe.
Does anybody has faced such a problem? How to solve it? (I use .NET v1)
Ok, here's the deal - I have two assemblies in a project along with a tester application. The tester application is dependant on (and references) both assemblies, but neither of the assemblies reference each other. I have set up the dependancies and references for the tester app in VS.NET (including setting the references to the assemblies to copy the referenced assemblies local). When i launch the tester application, i get a IO SystemException saying that one of the dll's or its dependancies can't be found, yet if i open explorer and look in the bin\debug folder, i can see both of the assembly dll's along with the tester executable.
the_grip wrote: When i launch the tester application, i get a IO SystemException saying that one of the dll's or its dependancies can't be found, yet if i open explorer and look in the bin\debug folder, i can see both of the assembly dll's along with the tester executable.
One or both of the assemblies probably has a dependancy on another assembly that is not in the progrm directory or the GAC.
Who is this miscrosoft, and what devilish plans have they for us?
That's what i initially thought, however, they only reference the base assemblies (System, etc.). There are no custom references defined that these are dependant on. Surely I don't have to copy these dlls... that should be in the environment path... or do i need to set these to copy local?
i should note that i had this problem once before... i had to strong name my assemblies and add them to the GAC before it would work. This was a few weeks ago, and i dumped that solution. Every time i rebuilt the assemblies i would have to reregister them in the GAC. Surely there is a better solution (i can't imagine having to do this just to test assemblies)?
Thx leppie... i downloaded all those proggies off that page... good stuff.
i DID manage to finally find my problem. i was referencing the debug dll's for the assemblies (wrong), co i changed it to reference the assembly projects (right). i could have used the release dll's i guess, but this way solved my problem.
Oh well - there's another hour or two down the tubes on stupid troubleshooting errors Thanks again for the help.
The Debug configuration of your program is compiled with full symbolic debug information in Microsoft format and no optimization (optimization complicates debugging, since the relationship between source code and generated instructions is more complex).
The Release configuration of your program is fully optimized and contains no symbolic debug information. Debug information may be generated in separate PDB files.
Debug modes also generate IL when using the System.Diagnostics.Debug class, such as Debug.WriteLine (just like Trace except only applies in Debug modes). When you compile without DEBUG set (i.e., release builds), the compiler ignores these statements. This way, you don't have to worry about a lot of preprocessor conditions or finding all the tracing in your code. Leave it - it won't be compiled when you release.
"Well, I wouldn't say I've been missing it, Bob." - Peter Gibbons
depends what you are trying to do.
if the pointer is allocated externalling (i.e. by an api call rather than a managed call) then you don't need to worry as it will not move.
if it is allocated by managed code then you only need to lock it when you are calling external functions...
"When the only tool you have is a hammer, a sore thumb you will have."