If I get to the end of this project with some hair remaining and my sanity intact then possibly :) I'm still having issues with this actually. Everything I see in SQL Profiler now runs fine if I copy it and run it manually, so I don't know where the rollback is coming from. I'm currently wondering if we can just give the users a fancy looking frontend and ask them to write all the important data down somewhere...

Ignore me. In fact, don't ignore me, let me serve as an instructional example. Don't forget that NHibernate is going to do some funky stuff with transactions, and if any of your database operations fail, chances are they're all going to fail. Furthermore, you probably won't get to know about it through conventional means either.

Hi, I've got an issue with NHibernate and it's causing me all sorts of headaches. I have a routine which takes an object and manipulates it into an appropriate state, then supposedly writes it to a database. What I'm seeing is that when I run SQL Profiler against the database, all the inserts and updates I'm expecting are present, but when I go to look at the database itself, the data has not been updated. Anyone ever experienced this? If I go back to Profiler and copy and paste the SQL into Enterprise Manager, then run it, everything happens as expected, the records are created/updated and everything looks fine. Profiler does not give any indication that anything went wrong with the transaction and I'm struggling to see what's going wrong. How can Profiler claim that the data has been written when it manifestly hasn't? If anyone's got any ideas I'd be really grateful.

and it does in fact work a treat. One for the file, I think.

Hmm... not what I was actually after, but much better in fact. That will work nicely. Thank you.

I want to be able to put an entry in my app.config so that, regardless of the user running the app, it will still point to their "My Documents" folder. The user's PCs are very locked down, and all they have access to is that folder, but obviously that folder is in a different location on every PC. Is there a way to use an environment variable or something, so that it always points at "My Documents" for the current user, wherever that is?

I've used xsd.exe to great effect in the past to generate classes from xsds, but what I'd like to do now is do the same thing at runtime. The idea is to provide a plugin-type architecture where xsds can be dumped into a certain location and on its next run my application will pick them up, generate code from them and add that code to itself. I can't go into specifics too much, but I can give a more general example: Imagine an app that by default only knows how to handle certain xml files. What I want to do is essentially provide that application with the ability to understand other document types by giving it a definition (xsd) of what those types look like. From the definition the app will be able to generate classes from which it can instantiate objects of the document's type. Assuming the generated class conforms to an interface (which it will) generic code can then be written to use any document type without knowing anything about that type in advance. I'm not too concerned about the more theoretical bits here, I'll try that myself and see if it works as I think it should, but if anyone has any examples of how a class can be created from an xsd, so I can perpetrate this madness I'd be grateful.

I was about to post something to the same effect when I spotted this comment. I've read quite a lot of stuff around this over the years, from various sources. It might look suspicious at first glance, but really, if you're compiling your calendar, and each 52 year period has a name, and there are all these intricate rules (I seem to remember something about great-calendars of many more years too, possibly 3600), would you really want to actually tie down all this information for dates many hundreds of years in the future when you're dealing primarily with the here and now? As a case in point, lots of programmers in the late 20th century coded all their dates with 2 figure years, because it saved space and they were only dealing with the here and now. I think we all know how that turned out. No disasters, but some red faces and a lot of hype. If they were still around, there'd probably be some red faced Mayans running round trying desperately to codify a few more decades right now.

I have a project that references a couple of old COM dlls. Every now and then I get an error message when trying to debug the project, which tells me access has been denied to one of these COM references. It seems to be entirely random. I can't identify anything that causes it, and the only fix I've found is to remove the reference, make sure any local copies of the dll are deleted and then add it again. This seems ridiculous. Anyone else experienced this, or have any idea how I can prevent it?

I have the following code: IWshRuntimeLibrary.WshNetwork myWSHNet; myWSHNet=new IWshRuntimeLibrary.WshNetworkClass(); myWSHNet.AddWindowsPrinterConnection(@"\\ZEUS\HEAD013", "", ""); myWSHNet.SetDefaultPrinter(@"\\ZEUS\HEAD013"); I get the WSH Network object fine, and the new printer is created without any problems. What doesn't work is setting it to be the default printer. Anyone any ideas why?

I'm trying to do something that might actually be a bit silly. I'm accessing what is essentially a windows form from an aspx page, to do some printing from the server side for me. I have the following code:

public class axForm : System.Windows.Forms.Form
{
public AxDHTMLEDLib.AxDHTMLEdit axd;
public axForm()
{
Thread.CurrentThread.ApartmentState=ApartmentState.STA;
axd=new AxDHTMLEDLib.AxDHTMLEdit();
((System.ComponentModel.ISupportInitialize)(axd)).BeginInit();
this.Controls.Add(axd);
axd.Enabled = true;
axd.Name = "axd";
((System.ComponentModel.ISupportInitialize)(axd)).EndInit();
}

public void printDoc(string sHtml, bool bPrompt)
{
	axd.DocumentHTML=sHtml;
	object filename=@"c:\\fileouttest.txt";
	for(;axd.Busy!=false;)
	{
		System.Windows.Forms.Application.DoEvents();
	}
	axd.SaveDocument(ref filename);
	object opt=null;
	if (bPrompt)
		opt="1";
	axd.PrintDocument(ref opt);

		
}

}

Basically I create an instance of that class in my aspx code behind, then call printDoc with the HTML I want to print and an indicator as to whether or not I want to see the print dialog (I don't but the code I based this on had the boolean in there and I thought it might be useful for testing). The problem is I'm getting a HRESULT error message and I don't know what to do about it. I'm guessing, since the error is fired just after the .endInit() line that it's something to do with how I'm setting the thing up in the first place, but I don't know enough about it to be able to debug it properly. The error is:

'System.Runtime.InteropServices.COMException' occurred in system.windows.forms.dll - Additional information: Exception from HRESULT: 0x80040200.

Can anyone help me figure this out? It seems like I'm really close to getting it working. If I tone down the amount of debug information I want, it actually runs without giving any errors at all, and the line that saves the document to disk actually works regardless, so I'm a bit confused. Any help would be greatly appreciated.

If it helps at all, I can now discount the notion that it's going to the wrong printer. I set the default printer programmatically and it still doesn't print anything. Any help would be appreciated, particularly from those of you more familiar with COM and ActiveX than I am.

Further to my last post in here, I've been doing some playing around with various bits of ActiveX and all sorts of other things in an effort to get my app to print nicely rendered text when handed a bunch of HTML. I think I'm pretty close. I managed to get all the bugs I can see ironed out, but now I've got what's either silent failure or a different kind of success than I was expecting. Bear with me while I try to explain what I've done, it's a little unconventional. To test with I've set up a page on which the page load event sends some HTML to my print routine. My print routine consists of a new class which inherits System.Windows.Forms.Form (I know, but bear with me). This class creates an ActiveX object (the MS DHTML editor control), passes the HTML string to it as its content, and then asks it to print. I found that, while there are all sorts of problems with printing without displaying the print dialog from a web browser control, the DHTML editor doesn't seem to mind and gives exactly the same result. Anyway, after a lot of messing around with this (as you can imagine, including a windows form in an ASP.NET app caused me a little confusion), I've got to the point where I can load my page, and no errors arise, but I don't get anything out of the printer either. The ActiveX control is being called fine, there are no errors there, but the printout just doesn't arrive. The app has identity impersonate set to true, so I figured it would use the logged on user's default printer, but that doesn't seem to be the case. My next thought was that it might be using the aspnet process's default printer, if such a creature exists, but I don't know how to test for that. Anyone have any ideas on how to resolve this? I feel like I'm really, really close and just need a bit of a nudge.

So... it might be possible to run a web browser instance on the server, insert the HTML I want to print, and tack the javascript on the end? That's kind of intriguing, I'm going to take a look at that. I suspect some of the posts further down that page mean that I'm not likely to get very far, since MS seem to have locked that functionality down in XP, but... the server in question is running 2000... Hmmm... Thanks, I'll look into this and see how far I get.

Fortunately I'm still in a 1.1 world! How do I get around the print dialog?

Hi all, I've got a small issue I need to figure out and I thought someone might have the answer. I need to send a print job (HTML page) to a networked printer connected to the web server, rather than the client's printer. Essentially this is a letter printing exercise for a corporate application. The letters are written with a wysiwyg, web-based HTML editor. They can then either be printed (for posting to the recipient) or emailed (which is, as you would expect, a doddle). Printing is causing some issues in that, while it's extremely simple to get a print job to a client-side printer, printing to a printer connected to the server is a bit of a nonsense. I thought of creating an instance of a web browser control on the server side and programmatically filling it with the HTML and asking it to print, but apparently this will pop up a dialog on the server, which is less than desirable. At the moment my solution is to do some fairly arcane transformations on the HTML in order to turn it into postscript, fire the postscript at a printer (which is relatively easy), and hope to god the printer understands it. Most of ours are HP printers and cope admirably with being given raw postscript, but it's not really a future-proof solution. If the users end up getting a new printer that doesn't understand postscript natively, they'll just be printing what will look like complete gibberish. If anyone's got a nice, slick answer to this, I'd appreciate it. The postscript solution has a certain raw charm, but it's nowhere near as elegant as it should be. Something I can actually show my boss without being slapped round the back of the head would be good.

I'd put sourcesafe at the absolute bottom of the pile. It's eaten more of my source than I care to contemplate. I'd suggest they take the "safe" out of the title, but then it'd just be "source" and that's silly. Subversion is unquestionably the way forward. I use it on my projects at home, but work is pretty tied in to Microsoft, and while the development team all believe sourcesafe to be the steaming pile of dingoes gonads it is, we're a little hampered when it comes to getting anything else.

The work they're currently doing on System.Windows.Forms should sort out the current issue with having to create multiple GUIs (or use GTK... *shudder*). As I understand it, they're reimplementing System.Windows.Forms by using System.Drawing, so the .NET app actually draws its own forms, regardless of what platform it's on. At least I hope that's what they mean. I'll have a play with the ASP.NET stuff in mono. I didn't manage to download it last night. I fell asleep practically as soon as I got in, which makes me feel horribly old.

I tried an earlier version (but not too long ago), your post prompted me to take another look. While I'm impressed that they're making headway with the windows forms stuff, I still don't think I'd be comfortable specifically targetting mono. When I first heard about the project, I thought it looked great, but looking at it more closely I realised that in order to write a truly cross-platform app with it, without unnecessarily introducing windows users to GTK#, was still a bit of a leap. The way they're currently attempting to manage the System.Windows.Forms stuff is encouraging and should hopefully provide a better route for cross-platform development. I'd like to see mono actually *be* the .NET solution for other platforms, rather than something that looks a lot like it, but doesn't quite work the same. That said, I'm going to go home and install it on my web server in order to test just how good the ASP.NET implementation is. That's one area where it might just be mature enough for prime time. Don't get me wrong, the above isn't meant to be a criticism of the mono project. I think it's a great idea and I think they've made phenomenal progress, I just don't think I'd want to build a full-blown application with it just yet.

I can see the point of this approach, providing you're only talking about developing for one platform. The minute you're looking to provide something either for a platform for which your shiny new language isn't available or for multiple platforms, that falls down. If I'm writing an app for a windows environment, I'll almost certainly use C#/.NET, if I'm writing an app for Linux or Solaris or Mac OS, I'll have to do a bit more thinking. Alright, so it's possible to code C# for Linux (and other targets) with mono, but it's not really at a point where I'd be happy doing so, so that leaves me with other options. If it's a quick and dirty job (as most of mine tend to be, requests generally coming in the form "I want $foo and I want it yesterday!") I'll most likely go for something like Tcl/Tk. If it has to be a bit more robust, my skillset is likely to lead to me hunting around for my C books. If shiny new coding options were available across the board then it'd be different, and I'd most likely standardise on the intersection between what's most current and what I know best. As it is, they're not, and I have to keep a few odd bits and bobs floating around in my brain, just in case they're ever called upon for an odd situation.