Striving for Laziness

Publishing Symbol Data with a Manual Build

cgreene — Wed, 10 Oct 2012 22:55:13 GMT

I was recently working with a customer where an automated build process was not possible. Thus, we couldn’t use the steps found in Publish Symbol Data. After a few hours of research, here’s what we did:

Install the Debugging Tools for Windows. This is needed because we’ll be using SymStore.exe.
Create a network share for the symbol store. Make sure the account you use to do the build has write permissions.
Add a Post-build event with a command line like this:

"%ProgramW6432%\Debugging Tools for Windows (x64)\symstore.exe" add /r /f "$(TargetDir)*.pdb" /s \\server\symbols /t $(ProjectName)

Pretty easy. SymStore.exe has several command line parameters. So there are many more options to choose from to suit your needs.

C-Style Array COM-Interop

cgreene — Wed, 10 Oct 2012 18:02:25 GMT

You are developing an application with large arrays and you want the best of both worlds. You want to use the .NET Framework for the ease of creating managed applications but you also want to use Native Code so that you take advantage of hardware accelerators like GPGPUs (for which you would consider C++ AMP) or Auto-Vectorization.

The managed application in this post performs vector addition and dot products on C-style arrays. It shows you how to pass C-style arrays to and from Native Code. There’s already a post on using C++ AMP from C# that uses P/Invoke. This post will show you how to do it through COM Interop with C++/ATL.

The dot product and vector addition implementations are basic because there are already several posts on the Parallel Programming in Native Code blog to bring you up to speed with these new technologies for even faster execution. This post also assumes you are familiar with basic Visual Studio, C++ and C# development.

Let’s get started.

1. Start Visual Studio with elevated privileges. (It has to be elevated so you can register your COM object)

2. Create a new Visual C++ ATL Project. I called mine “NativeVectorOps”. (Since there’s existing documentation on how to create ATL projects as well, I won’t get into the details here)

3. Define the interface (this listing does not show the IDL attributes)

interfaceICVectorOps : IDispatch{

HRESULT Add(DOUBLE a[], DOUBLE b[], int size, DOUBLE c[]);

HRESULT DotProduct(DOUBLE a[], DOUBLE b[], int size, DOUBLE* c);

};

4. Build the ATL project. This will also register your COM DLL. [Note: If you build this as a 64-bit binary, you’ll have to set the Target Environment to “Microsoft Windows 64-bit on x64 (/env x64)” on your ATL project]

5. Open a Visual Studio Command Prompt and create the Interop Assembly with the following command line:
tlbimp NativeVectorOps.DLL

This creates a new interop assembly named NativeVectorOpsLib.DLL

6. Disassemble the Interop Assembly. From the Visual Studio command prompt, run
ildasm NativeVectorOpsLib.DLL /out:NativeVectorOpsLib.il

7. Now it’s time to fix the Intermediate Language (IL). By default, tlbimp will only create an interop assembly that passes arrays as a pointer. Not a big deal. You could certainly use this. I just want to use the C-style arrays because I prefer not to use pointer arithmetic.

Open NativeVectorOpsLib.il in your favorite text editor.

8. You’ll have to change each method twice. Once for the interface and once for the class. We’ll start by fixing the Add method:
Before:

.method public hidebysig newslot abstract virtual

instance void Add([in] float64& a,

[in] float64& b,

[in] int32 size,

[in][out] float64& c)

runtime managed internalcall

After:

.method public hidebysig newslot abstract virtual

instance void Add([in] float64[] marshal([+2]) a,

[in] float64[] marshal([+2]) b,

[in] int32 size,

[in][out] float64[] marshal([+2]) c)

runtime managed internalcall

The “&” is the interop assembly default and it signifies the parameter was passed as a pointer. The [] marshal([+2]) says it should be passed as a C-Style array. The marshal “+2” part is a zero-based index which tells the interop layer which method parameter contains the size of the arrays. In this case, +2 turns out to be the size parameter.

9. Now we’ll change the DotProduct method. Remember – you’ll have to do it twice.

Before:

.method public hidebysig newslot virtual

instance float64 DotProduct([in] float64& a,

[in] float64& b,

[in] int32 size)

runtime managed internalcall

After:

.method public hidebysig newslot abstract virtual

instance float64 DotProduct([in] float64[] marshal([+2]) a,

[in] float64[] marshal([+2]) b,

[in] int32 size)

runtime managed internalcall

Again, we’re just replacing float64&with float64[] marshal(+2).

10. Save NativeVectorOpsLib.il

11. Now it’s time to reassemble the interop assembly. From the Visual Studio command prompt run the following command:
ilasm /dll NativeVectorOpsLib.il

This recreates the NativeVectorOpsLib.DLL assembly.

12. Create a managed project like a simple C# console application. I called mine VectorClient.

13. Decorate the Main method with the STAThreadattribute.

14. Add a reference to the NativeVectorOpsLib.DLL assembly.

15. Here’s the code:

[STAThread]

staticvoid Main(string[] args)

{

// Define a couple of arbitrary arrays

double[] a = { 1.0, 1.0, 1.0 };

double[] b = { 2.0, 3.0, 4.0 };

// Instantiate the Native COM Object

NativeVectorOpsLib.CVectorOps vectors = new CVectorOps();

// Calculate and print the dot product

double dotProduct = 0.0;

dotProduct = vectors.DotProduct(a, b, a.Length);

Console.WriteLine("{0} . {1} = {2}", FormatArray(a), FormatArray(b), dotProduct);

// Calculate and print the vector addition

double[] c = newdouble[a.Length];

vectors.Add(a, b, a.Length, c);

Console.Write("{0} + {1} = {2}", FormatArray(a), FormatArray(b), FormatArray(c));

}

publicstatic string FormatArray(double[] array)

{

StringBuilder sb = new StringBuilder();

sb.Append("{ ");

for (int i = 0; i< array.Length; i++)

sb.Append(string.Format("{0} ", array[i]));

sb.Append("}");

return sb.ToString();

}

And that’s what it takes to do C-style arrays with COM interop. That wasn’t too bad, was it?

UserProfileApplicationNotAvailableException

cgreene — Tue, 24 Aug 2010 18:05:36 GMT

I was experimenting with the SharePoint 2010 User Profile Service. I had a simple console application and used the code found in the UserProfileManager documentation as a starting point. But any time I tried to create a new UserProfileManager object I got an UserProfileApplicationNotAvailableException.

I made sure I followed all of the steps in Configure profile synchronization but I still was getting the exception.

Steve Peschka finally pointed me to his post on "No User Profile Application Available" Mystery in SharePoint 2010' and that solved it.

Remote Smart Card Authentication

cgreene — Tue, 26 Jan 2010 17:28:08 GMT

I was trying to remote into a Windows 7 Hyper-V guest from my Windows 7 laptop using my smart card for authentication. When I initiated the remoting session I made it all the way to the “Welcome” screeen, but then received the following error:

“The system could not log you on. An error occurred trying to use this smart card. You can find further details in the event log. Please report this error to the system administrator.”

This is the same error message highlighted in KB article 939682.

Here’s how I solved the problem:

Log on to the machine using username/password credentials
Open Device Manager
Right-click the top node in the details pane (this will be your machine name), select “add legacy hardware”
Click next when the “Welcome to the Add Hardware Wizard” appears
Select “Search for and install the hardware automatically (Recommended)” and click Next
Click Next again on the screen that says “The wizard did not find any new hardware on your computer”
Scroll down, select “Smart cards”, and click Next
There will be a few drivers listed. Select one and complete the wizard.
Log out and try to log back in using the smart card
Repeat the process until you find a driver that works for your smart card

Little Blessings

cgreene — Tue, 04 Aug 2009 18:41:17 GMT

It’s nice to talk about things other than technology.

A few weeks ago my wife, Laura, and I went home to visit my family. We ended up finding four puppies in the woods. Between the four of them they easily had 200 ticks and so many flees it looked like their skin was crawling. It was apparent they had been in the woods for a while. They were all very malnourished. One of the females in particular probably would not have made it more than a day or two. Fortunately, the people at Jackson Square Animal Clinic in Oak Ridge, TN took excellent care of them and they began to perk up a few hours later with the help of my family.

We found homes for all but one. So Laura and I felt like the final one would fit in great with our family. My niece, Hannah, wanted to name Spotty. My nephew, Hayden, couldn’t remember ‘Spotty’ so he called him Polka dot. When we renamed him to Banjo, Hayden called him Alphabet.

So we decided his full name will be Banjo Alphabet Polka Dot Greene.

FDCC Development Requirements

cgreene — Thu, 09 Jul 2009 00:38:28 GMT

I posted an entry over on the FDCC Technet blog on how to best develop desktop applications. It can be found here. It covers the most common problems encountered when developing applications on the FDCC.

Would you like to see other problems/issues discussed in future posts?

Creating Debug and Release SharePoint Solution Packages

cgreene — Thu, 19 Feb 2009 02:11:00 GMT

I’m lazy. It’s true. And I’m always looking for ways to be even lazier when developing software. I want my tools and build system to do as much heavy lifting and perform as many repetitive tasks as possible.

In addition to being lazy, I’m also human which means that I occasionally make mistakes. So I want to let my tools to provide guardrails while allowing me to minimize the amount of mouse and keyboard input.

To briefly sum it up, I want to minimize my workload and minimize mistakes.

This is the first of hopefully many entries on that topic. I’ll focus on SharePoint for now since that’s where I spend the greatest amount of time and there are many repetitive tasks.

This post demonstrates how to create Debug and Release SharePoint Solution Packages. There are several other enhancements I’ve made to enable my laziness, but I’ve left most of them out of here to stay focused on the topic. I’ll try to cover the other enhancements in future posts.

I learned how to build SharePoint solutions using this method from Ted Pattison. (See Creating a Solution Package in Windows SharePoint Services 3.0) I’ve stuck with it because it has always worked for me. The only problem is that the path to the Debug or Release assembly has been hard coded in the DDF. Furthermore, I also use Team Foundation Server for source control and I don’t want to check in/check out my DDF every time I have to make this change. But because I’m lazy and prone to making mistakes, I want to avoid any manual input and use Visual Studio’s Solution Configuration to build the Solution Package with the correct output assembly. (See Build Configurations). The idea is that if I want to create a WSP that contains the Debug assembly, I just set the correct solution configuration and build my project. Or if I want a WSP that contains the Release assembly, I just set the solution configuration to Release and build the project. All of this should only take 3 or 4 clicks of the mouse.

I automate the creation of my SharePoint solution package any time build. Thus, I have a custom MSBuild Target that calls MakeCab.exe when my Visual Studio 2008 project builds. I derived this from the work of Andrew Connell. (See Automating Solution Package Creation for Windows SharePoint Services by Using MSBuild)

My Targets file looks something like this:
<?xml version="1.0" encoding="utf-8"?>

</Target>

...

</Project>

BuildSharePointSolutionPackage is a relatively simple Target. It just calls MakeCab with a few arguments. Variables are passed in with “/D” followed by a VariableName=Value format. BuildType is the name of a variable passed into MakeCab. Its value is set to $(ConfigurationName) which is an environment variable that Visual Studio 2008 replaces at build-time with “Debug” or “Release”.

/F Solution\cab.ddf tells MakeCab to where to find the DDF relative to the project directory.

Last point on the Targets file: If you’re paying close attention you might have noticed a slight difference between my targets file and Andrew Connell’s. I’m lazier than he is, so did not install the CabSDK or set a PropertyGroup to the path of MakeCab since it already ships with Windows Server 2003 and Windows Server 2008 and is in the path.

Now, let’s move on to the DDF. It looks like this:
;Sample DDF
.Set DiskDirectoryTemplate=CDROM
.Set UniqueFiles=”ON”
.Set DiskDirectory1=Package
.Set CabinetNameTemplate=Sample.wsp

Solution\manifest.xml                manifest.xml
TEMPLATE\FEATURES\Sample\feature.xml Sample\feature.xml
TEMPLATE\REATURES\Sample\types.xml   Sample\types.xml
bin\%BuildType%\Sample.dll           Sample.dll

The last line of the DDF contains the %BuildType% variable to the path of the output assembly. When the BuildSharePointSolutionPackage target calls MakeCab and passes in the BuildType variable, the last line becomes:

bin\Debug\Sample.dll Sample.dll

OR

bin\Release\Sample.dll Sample.dll

With this infrastructure in place, simply select a Debug or Release configuration from Visual Studio 2008 and then kick off a build. The BuildSharePointSolutionPackage target will take care of everything else.

One final caveat: When passing custom variables to the MakeCab command line, you will not be able to use .OPTION EXPLICIT or .Define in your .DDF. I verified with a few guys from the product group.

So there you go. We set up our Visual Studio 2008 project to create Debug and Release builds of a SharePoint Solution Package.