1: public class SampleClass

   2:  {

   3:      private List<string> myList = null; 

   4:  

   5:      public SampleClass()

   6:      {

   7:          myList = new List<string>(); 

   8:      }

   9:  }

There are a couple of ways you could write the method; it also depends on what are you trying to achieve. Below are some of the samples how you could do this (yes, I know, there are probably million other ways to do this :)):

   1: public void AddItem(string item)

   2: {

   3:     // Do something 

   4: }

   5:  

   6: public void AddItems(List<string> items)

   7: { 

   8:     // Do something 

   9: }

  10:  

  11: public void AddItems (string [] items) 

  12: {

  13:     // Do something 

  14: }

Every method above has it’s benefits and drawbacks – I have to pass in an array of string, I can only pass in one string a the time, sometimes I want to pass in 3 strings and sometimes 1 – why can’t I use one method only?).

There’s a keyword called “params” you could use to solve this problem – with this keyword you can pass in as many parameters as you like; for example all calls below are made to the same method:

   1: SampleClass my = new SampleClass();

   2: my.AddItems("One"); 

   3: my.AddItems("One", "Two");

   4: my.AddItems("One", "Two", "Three"); 

And here’s how the method would look like:

   1: public void AddItems(params string[] items)

   2: {

   3:     foreach (string item in items)

   4:     { 

   5:         // Do something

   6:     }

   7: }

 Guid myGuid = new Guid();

Everything worked fine, no errors, no exceptions, nothing. If you check 'myGuid' you would see that the guid is indeed assigned to the variable. But the problem is that the guid is empty (e.g. {000...000}). Instead of spending time on researching what else could went wrong, I didn't even think about that line. Once I changed the above line to: Guid myGuid = Guid.NewGuid () - everything was working fine.

I guess the 'lesson' is - check the most obvious things first - I usually tend to skip over the obvious stuff because 'I know that's right' and 'It can't be that simple'. Well, looks like sometimes it is :)

If you are interested in SharePoint, Visual Studio, Office, VSTO or any other combination you should head over to our team blog (https://blogs.msdn.com/vssharepointtoolsblog) and subscribe to it.

Imagine you are testing a product localized to Arabic language (or any other language you don't know how to read, write or you don't understand it). If you are familiar with the product in your language of preference then the task of finding buttons, windows and other things in the user interface shouldn't be a big problem (but yes, it still can be a pain). But what if you get an error message in that language?

You would probably agree that it can be very hard to quickly find someone who speaks those languages. There's a Live Translator website you can use to translate the error message or any other text. There's also an addin up on Windows Live Gallery which adds a Translator button to your IE and can translate the web page you are currently looking at to 12 languages. Even though the translations are not perfect, it's usually enough to get the idea what the error is about.

If you don't like using machine translation there could actually be a second 'solution' to your problem - you can always install the product in language you understand and try to get the same error message. But what if you don't get that error message? Even if you do get the 'same' error message - can you tell with 100% certainity that the error message in let's say English language is the same one you are getting in other languages? That's the other story. Maybe there is a bug which is specific to the localized version?  You should definitely verify that.

Our team is still hiring.

If you are excited about VSTO, Office, SharePoint and Visual Studio this could be the right position for you. You can read more about the open positions here. The descriptions are quite extensive (take a look at both dev and test position descriptions) but if you still have some questions feel free to comment or contact me - my email is PeterJ (at microsoft.com).

You have nothing to loose if you send in your resume and apply for the position!

for (int i = 0; i < 10; i ++)
    for (int j = 0; j < 10; j ++)
          Method1();
    Method2();
Method3();

First question: Do you know how many times are the methods being called?  If you copy/paste the code and run it you will see that Method1 is called 100 times and after that Method2 and Method3 are executed. Looks good.

Now, imagine you are looking at that code someone else wrote and try to answer this question: Are you 100% sure that Method2() should be executed only once? Maybe the method should be executed only 10 times? Or maybe 100 times? It is a tough question and you probably can't answer it without asking the person who wrote the code some questions. I bet you there would be no ambiguity if you used parenthesis like this:

for (int i = 0; i < 10; i ++)
{
    for (int j = 0; j < 10; j ++)
    {
          Method1();
    }
    Method2();
}
Method3();

I remember when I was an intern in Dublin I wrote similar code (it was also a for loop) and I didn't use the parenthesis. Senior developer who was doing a review asked me the same question. Your code will be more readable if you use parenthesis in this case. Besides, you could also avoid some bugs.

I am not sure what the reason is, for not using parenthesis but a coworker told me about the another formatting 'issue' and the reason for it.

public void MyMethod (int arg1, string arg2, bool arg3) {
      DoSomethingHere ();
}

Notice in above code the parenthesis is inline with the method declaration. And apparently the reason for that was that back in the days the monitors didn't have high resolutions and writing the parenthesis in the same line saved you one line on the monitor screen.

I am guessing the reason people are still writing the code this way is only a habit and nothing else. I know everybody has his own style of coding and code formatting and this doesn't mean your code is bad.

Let me end this post with a short story that could apply to the above text. I read this in Steve Maguire's book Debugging the Development Process. The story goes like this:

"A boy asked his mother how come she cuts off the edges of a pot roast when putting it into the pot. Mother told him that that's how her mother taught her to do. So, boy went to his grandmother and he got the same answer. Then he went to his grand-grandmother and ask her the same question. The answer was: Well, back then my pot was to small and the meat didn't fit inside."

Old habits never die.

Sharepoint Development - Making Sense of it All - Part I
Sharepoint Development - Making Sense of it All - Part II

SPSite site = new Microsoft.SharePoint.SPSite("https://localhost");            
SPWeb spWeb = site.RootWeb;

SPList docLib = spWeb.Lists["My Document Library"];          
SPListItem folder = docLib.Folders.Add(docLib.RootFolder.ServerRelativeUrl, SPFileSystemObjectType.Folder, "My folder");
folder.Update();

using (FileStream fs = File.OpenRead (@"C:\TestDoc.doc"))
{
           SPFile file = folder.Folder.Files.Add("TestDoc.doc", fs);
           file.Update(); 
}

Before you run this code you must add a reference to Microsoft.SharePoint.dll which is located at:

X:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\Microsoft.SharePoint.dll

Also this code assumes that document library named "My Document Library" exists. If you want to create a document library you can use this code:

spWeb.Lists.Add("My Document Library", "This is my first document library", SPListTemplateType.DocumentLibrary); 

Looks like "Insert Code" plug-in works just fine ...

You create a new VSTO solution (Word document or Excel workbook) and you run the solution. Respective application will open and you make some changes to the document/workbook - maybe you add a few pictures, change text formatting, etc. Once you're done you save the document and close the application. You might be surprised to see that the changes you made are not reflected in the document designer inside Visual Studio. Don't panic - changes you made are not lost.  Reason you won't see any changes is that there are multiple copies of the document/workbook.

When you run the solution Visual Studio copies the document from solution directory to \bin\debug\ or \bin\release\ folder. This is the document that will open when you run your VSTO solution and this is the document where you made all your changes. But when you close the application and return to Visual Studio, the document opened inside VS is from your solution directory.

So, instead making changes to the document when you F5 the solution, do your changes inside Visual Studio  (if you're customizing an empty, new document) or create your solution based on existing document which was customized outside VS. Or you can open the document in \bin\debug folder and copy/paste the changes you made.