To force a C#App to run in Admin mode, just edit the manifest File to have the following Element:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
More Information on the Manifest File:
http://msdn.microsoft.com/en-us/library/bb756929.aspx
Previously I thought this was not possible, since the ASP.NET postback involves POST-ing the all-encompassing ASP.NET form, but I am here to tell you, that it is indeed possible to do a postback to a new window or even a popup (created with window.open). In fact, it is surprisingly simple. All you really have to know is that the “target” attribute you know from anchors (links) works exactly the same way for forms!
Continue reading ASP.NET Postback to new Window or Popup
The Microsoft SQL Server Management Studio (even v2008 R2) has problems with executing large SQL-files. To execute these files you need to use the sqlcmd Utility.
Sample usage:
sqlcmd -S myServer\instanceName -i -U loginname -P password C:\myScript.sql
Today I’ve had an extremely interesting realization: the number, order and exact point in the page lifecycle at which HtmlMeta controls are added to the HTML head can have significant implications for your page. Especially if you have some sort of “transient” meta tags that are only added to the page when it is initially loaded, but not after a postback. When you call the
myHeadControl.Controls.Add(myHtmlMetaControl)
method, every control that doesn’t have a manually set ID will be assigned an automatic ID by its naming container (ctl00, ctl01, …). This doesn’t seem too bad until you realize that this means that the ID of your very important custom control can change from “…ctl08…” during initial page load to “…ctl04…” in a postback. And THAT is a problem. Because the way that the view state is restored to the control tree is directly through those control IDs. Actual results can vary from mismatched control values to view state exceptions and lots of other hard-to-trace problems.
Continue reading Prevent automatically generated IDs for controls
This is for now just a bucket with helpful resources:
Yesterday, I made my first multithreaded tests with XNA 4.0.
I started with my own WorkerThreadManager, a BlockingQueue and some WaitHandles to setup a Worker-Queue and Workers. The testproject was a an XNA-App just drawing circles and move them around (with collision detection on the walls). The first test was rather disappointing. I could run about 4x more circles in single-threaded mode than with multi-threaded approach.
After some profiling, I found that the BlockingQueuewas the bottleneck. I then found the class BlockingCollection from .Net 4.0. Using that one improved the speed quite a bit but still about 3x slower than the single-threaded one.
After some more research, I stumbled accross the brand-new System.Threading.Tasks Namespace with some quite interesting classes.
I could replace my whole ThreadManager with this little piece of code:
List<Agent> agentList = SomeHowGetSomeAgents();
Task[] tasks = new Task[agentList.Count];
for (int index = 0; index < agentList.Count; index++)
{
Agent agent = agentList[index];
Task t = Task.Factory.StartNew(() => DoSomeWork(agent));
tasks[index] = t;
}
Task.WaitAll(tasks);
Nice, eh. That further improved the speed but again, it’s still about 2x slower than the single-threaded one…
So I found one more class called Parallel.
With this class, the code now looks like:
List<Agent> agentList = SomeHowGetSomeAgents(); Parallel.ForEach(agentList, DoSomeWork);
That one finally runs faster than the single-threaded approach. Three times faster!
I might need to redo all those tests when the DoSomeWork is much more sophisticated. But for now, Parallel seems the way to go for simple Worker-Threads.
Time for some more fun with VisualStudio macros.
Lets consider this common scenario: You open a project to make a minor adjustment and then realize that in order to compile that project, you need to add all the dependencies (project references) to your solution. For larger projects, that could be a LOT of projects to add… AND you may have to do this recursively! take a look at the reference, locate the project file, add it to your solution, repeat. Since I am indeed THAT lazy, I created a macro to do that for me.
Have you ever tried adding a new reference to lots of projects in a very large application? If you have, you know this already and if you haven’t, let me tell you: it gets old really fast… Open project, right click the project, click on “Add Reference…” and so on. As an inherently lazy demographic, this simply is not an options for us developers. So what do we do? We automate it with a VisualStudio macro.
If you need to debug in special condition, like you got a loop and you want to debug the 34th item, you could either set a breakpoint and just skip it 33 times (by pressing f5) or you could simply add a condition to this breakpoint.
You do this by right-clicking the breakpoint and choosing "Condition...".
There you can enter any valid C#-Expression, like "ssList[counter] == 1947635". Now the breakpoint is only hit if this condition is true.
For quite some time now, it has happened to me occasionally that attaching the debugger to the w3wp.exe (IIS worker process) to debug a web application gets extremely slow. I’m talking about several minutes to load all the symbols before it could actually start debugging. In the VS status bar you could see that it took about 1 second for each assembly to load – and we’ve got LOTs of them. In the past, the problem usually went away by itself after a reboot or some other Windows “feature”. This week however it just didn’t get any better. After some Googleing I now think that I have found the solution to the problem: simply delete ALL breakpoints and set a couple of new ones. Don’t ask me how or why exactly, but it seems to be quite reliable.