PlausiblyDamp

Would the DLL also define the data type or would that be defined elsewhere? If the DLL defines the data type would the user be expected to also design this as part of the DLL creation process? If you just want to store data then simply putting it into an XML file may be an easier job. Unloading Dlls at runtime can get interesting clicky 1 clicky 2 as you cannot do it without unloading an entire AppDomain. It may be worth posting a bit more information about exactly what these Dlls would be used for and what level of customisability would be required at run time.

There are a few available obfuscators which will make the program harder to disassemble the following being two such products. http://www.wiseowl.com/products/products.aspx http://preemptive.com/products/dotfuscator/index.html Although if you wish to hide a serial number you may be better of looking at using some form of encryption instead.

Not sure if there is a managed equivalent but the following declaration should work [DllImport("ole32.dll")] static extern int CLSIDFromProgID([MarshalAs(UnmanagedType.LPWStr)] string lpszProgID, out Guid pclsid);

If you do a rebuild rather than a build do you still get this error? Have you recently removed sub projects and then added them to a new solution? Happened to me recently and after doing a rebuild the problem seemed to go away.

Could you now use it's .Items.IndexOf to see if it finds an existing match?

In C# using is actually used for two differerent purposes one is the equivalent of VB's imports the other is just a nice clean way to ensure .Dispose is called on objects that require their cleanup to be run at a known point (DB connections, file handles etc). In the next version VB also gains the Using command though.

Data access under .Net is very different that DAO or ADO and although these technologies can be used with .Net you are probably better off learning the ADO.Net way of doing things. The following links are worth a look http://www.xtremedotnettalk.com/showthread.php?t=69746 http://samples.gotdotnet.com/quickstart/howto/doc/adoplus/ADOPlusOverview.aspx http://www.xtremedotnettalk.com/showthread.php?t=83993

STAThread denotes the thread that is running the Main routine will be a Single Threaded Apartment model - this only had any meaning to COM and was a work around for certain issues when dealing with COM interop in the 1.0 Framework. In most cases it wasn't needed and since the 1.1 framework has been released and the bugs fixed it is totally un-needed now.

If they are .Net dlls then they don't need to be registered on the target system - one of the advantages over COM.

If you are doing a lot of server side code then the WebControls offer a much richer programming model and automatically target the browser in question. If on the other hand you are either migrating from asp / HTML or are involved with a lot of client-side scripting then the HTML controls will be more familiar.

Could you post the code for the Leave event? Also is there any code in either the Validated or Validating events?

C# was designed with the .Net framework in mind so there is a certain argument for using it, it also does have a few features that VB.Net doesn't. The main difference though is really just syntax - some people prefer the C# style of curley braces and semi-colons other people prefer the VB style of syntax. Then again some people have an opinion they confuse with fact and deem all other opinions to be wrong - try to avoid being swayed by such ignorant arguments. I personally would try to get experience with both VB.Net and C# - the framework is the same so you only learn that once, often you find samples and articles in only one or other language so being familiar with both makes your life easier and finally if you are familiar with both then you increase your own personal marketability when job hunting. Also VB.Net is gaining more of the C# features in the next version anyway so from anything other than a Syntax / style point of view the differences are getting smaller.

Not part of VBScript but part of VB.Net.

If you implement IComparable then your class / structure can be used anywhere the IComparable interface is expected, including parts of the .Net Framework (e.g. Array.Sort) If you coded your own function then you would only be able to use it in a limited number of places (i.e. your own code)

In that case use DirectCast instead of CType

As C# is also a .Net language you will probably find you are already familiar with a lot of the concepts from your VB.Net experience. All you will need to learn for C# will be the different syntax and one or two other features (like operator overloading). I would recomend any VB.Net developer to get some exposure to C# (just the same as I would recomend any C# developer get some VB.Net experience) as you will often find articles / samples in the other language than you are developing in ;) As to the benefits of the C# as opposed to VB.Net style everybody has their own opinion as to which they prefer (personally I have no real preference - each does pretty much the same job and the differences in functionality are getting less in the next version anyway), but that's all it is a personal preference for a language style. I have very little doubt this thread will end up with one or two postings passing of their own opinions as fact - I recomend you try C# and make up your own mind, after all any extra knowledge looks good on a CV ;) C++ on the other hand is a different kettle of fish entirely, and although the syntax is similat to C# (that was one of C# design ideas) the way C++ language operates is very different. For example C++ allows multiple inheritance while .Net doesn't, IIRC C++ doesn't have interfaces (abstract classes would be used instead) while .Net does. .Net has automatic memory management through the Garbage Collector while C++ leaves a lot of this open to you (pointer arithmetic, having to track / free memory allocations) I wouldn't discount learning C++ but it isn't going to be as easy as C#, and if I was considering C++ I would definately start with something simple (console based app, basic IO) rather than Windows / DirectX.

Depends what you are converting between, to convert to a string all objects will implement a .ToString() method. Other data type often have their own method i.e. Integer.Parse() to convert a string to an integer.

If it is sending the encrypted data then you should either pass it as a byte array or if sendingf as a string then use a string safe format (e.g. base64) as the string that is getting sent appears to have a lot o finvalid characters.

If you have a look on http://www.sysinternals.com they have a utility called Process Explorer - that will be able to tell you what has the file locked.

The problem is down to two things In your aspx page within the <@Page > declaration you have AutoEventWireup = true set. This causes the framework to automatically invode the function named Page_Load on startup. You also have the Handles MyBase.Load declaration at the end of the page load function - this also causes the framework to invoke the page_load event. Hence it fires twice, either remove the handles mybase.load or set AutoEventWireup to false and the problem shoud go away.

Stepping through both the client and server things seem to go smoothly at first and the client logs the messages Attempting to connect to the server on port 8000. 'LicenseServerTools.exe': Loaded 'c:\windows\assembly\gac\system.xml\1.0.5000.0__b77a5c561934e089\system.xml.dll', No symbols loaded. Cennection established. Client requesting to trade public RSA keys. Client sending its public RSA key. Client Disconnecting The thread 'PrepEncryptionThread' (0x1a3c) has exited with code 0 (0x0). Attempting to connect to the server on port 8000. Cennection established. The server logs Connection Accepted Server sending its public RSA key. Server is waiting for the clients public RSA key. Server confirms client public RSA key recieved. Server Client Handeler exiting. The thread 'ServerClientHandler0' (0x2208) has exited with code 0 (0x0). Connection Accepted then it's call to ServerCommand = BR.ReadString() (line 460 in LicenseEngine.vb) seems to return junk (most definately not a string) and this is what causes eit to fall over. Not sure why but it doesn't seem to be in response to anything the client is sending though.... I will try to have another look later but that seems to be where the problem lies.

If you are implementing IComparable then you may as well just compare the fields yourself - using reflection will cause a performance hit for something as simple as this.

That would be because you are in the wrong dialog box - that is the add assembly dialog box. Try these steps 1 - in solution explorer right click on the name of your setup project. 2 - Move the mouse down to the option for Add. 3 - When the sub menu pops up select "merge Module" that's the one between file and assembly. 4 - Browse to the regwiz.msm file and select it. 5 - click on open. It should now be added as a merge module rather than a file or an assembly.

It looks as though you added it as a file rather than as a merge module - they are seperate menu options. In your screenshot the three msm files have been added as files, there is another listed that is callewd managed that has been added correctly - notice the slightly different icon. I've attached a small screen shot - the first regwiz.asm was added as a file while the second was added as a merge module, notice the differerent icon.

Any chance you could zip up the projects and attach them as I seem to be missing somethings if I just cut and paste your code?