|
Use C# and the SharePoint client side object model (CSOM).
If you get it right the first time, it should take about a month to build.
|
|
|
|
|
Gerry Schmitz wrote: it should take about a month to build
I could do it in half that time, with twice the amount of bugs 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Using the samples, yes. A new or existing data model? Maybe. No SharePoint experience? Good luck.
|
|
|
|
|
..wasn't intended seriously, but since I also confuse them often, a serious response;
Gerry Schmitz wrote: Using the samples, yes.
Ofcourse.
Gerry Schmitz wrote: A new or existing data model? Maybe.
If you change the specs, then either the deadline or the price moves.
Gerry Schmitz wrote: No SharePoint experience?
Some, that is why I said "twice the bugs".
Your chances of a succesfull demo in that case would equal zero; "some" means that there is always a prominent bug during a demo.
..and a similar big one right after the first release 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I was being rhetorical and not addressing anyone in particular
Just saying there are other considerations like data integrity, external user authorization, error handling and recovery, SharePoint "lists" maintenance ... which are all reflected in the code base.
|
|
|
|
|
I've had no problem in the past using WCF's DataContract/DataMember Attributes and serializing to XML with complex objects, including generic Dictionaries. But, after a few hours of reading up on WCF serialization, and reading posts on the usual places, I am stuck.
Here's a (down to the bare-bones for the sake-of keeping this short, .NET 4.5 code) example illustrating what I am trying to do.
using System;
using System;
using System.Collections.Generic;
using System.Runtime.Serialization;
using System.IO;
namespace WhatEver
{
public interface ISomeInterface
{
DateTime Date { set; get; }
}
public class BunchOfISomeInterface : Dictionary<Type, List<ISomeInterface>>
{
}
[DataContract]
public classLite : ISomeInterface
{
[DataMember]
public DateTime Date { set; get; }
}
[DataContract]
public classRegular : ISomeInterface
{
[DataMember]
public DateTime Date { set; get; }
[DataMember]
public extraString { set; get; }
}
public static class WriteMe
{
private static DataContractSerializer serializer;
static string filepath = @"C:\test.xml";
public static void Write(BunchOfISomeInterface bunch)
{
using (FileStream writer = new FileStream(filepath, FileMode.OpenOrCreate, FileAccess.Write))
{
serializer = new DataContractSerializer(typeof(BunchOfISomeInterface));
serializer.WriteObject(writer, bunch);
}
}
}
}If you call/use the above code using this in some .NET Class:
using WhatEver;
private void SomeTestClass()
{
BunchOfISomeInterface currentBunch = new BunchOfISomeInterface();
Lite lite1 = new Lite();
lite1.Date = DateTime.Now;
Regular regular1 = new Regular();
regular1.Date = DateTime.Now;
regular1.extraString = "extra";
currentBunch.Add(0, new List<ISomeInterface>());
currentBunch[0].Add(lite1);
currentBunch.Add(1, new List<ISomeInterface>());
currentBunch[1].Add(regular1);
WriteMe.Write(currentBunch);
}You'll get this error:
"An unhandled exception of type 'System.Runtime.Serialization.SerializationException' occurred in System.Runtime.Serialization.dll
Additional information: Type 'WhatEver.Lite' with data contract name"
I've tried several things here:
1. putting the [DataContract] Attribute on BunchOfISomeInterface: that gives an error that Bunch... cannot be serializable.
2. putting [DataContract] [KnownType(typeof(BunchOfISomeInterface))] Attributes on WriteMe: doesn't change the error.
3. I tried changing the ISomeInterface to be a Class rather than an interface: same error; that surprised me:
[DataContract]
public class ISomeInterface
{
[DataMember]
public DateTime Date { set; get; }
}That results in the same error message.
This thread on StackOverFlow suggests that you can't serialize Interfaces: [^], but I am not at a level with C# that I can grok if that's relevant here.
In other experiments I am getting the error: "Type 'System.RuntimeType' with data contract name"
thanks, Bill
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
modified 14-Sep-15 11:18am.
|
|
|
|
|
I don't know WCF, nor the DataContract, but..
..as which type of Duck would I deserialize an IFlying interface?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hi, Eddy, thanks for the "moral" support
Once you start using WCF's DataContract and DataMember Attributes to serialize/de-serialize, I predict you'll have a mighty "aha" moment, and never use any other technique. Just, as I found out the hard way, never think about using them to serialize some data collection of instances of an Interface.
By using the 'EmitDefaultValue option on the Attribute
[DataMember(EmitDefaultValue = false)]
public string OriginalValue { set; get; }
You can control whether the serialized file will contain, or omit, writing any description of a field if the field's value is the default value for that Type.
cheers, Bill
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
|
|
|
|
|
BillWoodruff wrote: Once you start using WCF's DataContract and DataMember Attributes to
serialize/de-serialize, I predict you'll have a mighty "aha" moment, and never
use any other technique.
I like how all those different techniques aren't easily interchangeable.
BillWoodruff wrote: Just, as I found out the hard way, never think about using them to serialize
some data collection of instances of an Interface.
Dunno if WCF supports it, but if the objects in the collection are serializable, then the collection is serializable.
..but you will have to know what type you actually are; the cannot be serialized as being IFlying, it has to be a MallardDuck or something. Then at deserialization you know what to recreate; since the type did not change, it will still have the same interface and can be added to a list.
BillWoodruff wrote: You can control whether the serialized file will contain, or omit, writing any
description of a field if the field's value is the default value for that Type.
I'll give a try next time I need to serialize a POCO at work
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
The concrete classes implementing ISomeInterface have to be known on both the server and the client. All those types which can be used here must be listed with a ServiceKnownType attribute.
And I'd suggest to replace typeof(BunchOfISomeInterface) with bunch.GetType().
|
|
|
|
|
Bernhard Hiller wrote: And I'd suggest to replace typeof(BunchOfISomeInterface) with bunch.GetType().
Why? Unless you're using a derived class, they'll both produce the same output, but the GetType call will be slower than the typeof call.
(See Jon Skeet's SO answer[^] for a benchmark.)
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thanks, Richard,
Of interest to me is that if you do use the technique of creating a field with a reference to the Type as Skeet suggests:
private static readonly Type BunchType = typeof(BunchOfStuff); While there's no problem using this as the 'Type argument to create a new 'serializer, if you are de-serializing, none of these will work:
public static Dictionary<string, List<Stuff>> Read()
{
using (FileStream reader = new FileStream(filepath, FileMode.Open, FileAccess.Read))
{
serializer = new DataContractSerializer(BunchType);
return (Dictionary<string, List<Stuff>>) serializer.ReadObject(reader);
}So, that's two places you've got to use the 'naked' Type declaration.
Perhaps you are aware of another method to avoid writing the 'naked' Type ?
cheers, Bill
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
|
|
|
|
|
You should be able to use:
public static BunchOfStuff Read()
{
using (var reader = File.OpenRead(filepath))
{
var serializer = new DataContractSerializer(BunchType);
return (BunchOfStuff)serializer.ReadObject(reader);
}
}
which at least avoids repeating the generic type definition.
However, there's no way to define a variable/field/parameter/property/return type using a type stored in another variable. The content of BunchType isn't known until run-time, but the return type needs to be known at compile-time.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thanks; what I can see (verified by experiment) is that if what you are serializing is a Class with the [DataContract] Attribute, you are correct.
The reason why I could not make that work is (hypothetically) that I was serializing a data-structure, not a class instance.
I'm going to assume that standard/best practice is to serialize a Class instance, and use ... that.
cheers, Bill
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
|
|
|
|
|
Thanks for replying, Bernard. I am just doing straightforward coding in .NET here, no client, no server.
After far too much wasted time, I have concluded that my question here is stupid in 2 ways:
1. experimentation suggests you can never use WCF to serialize some whatever/collection of instances of Interfaces, period.
2. what I wanted to achieve can be easily done by using the optional 'EmitDefaultValue parameter to the 'DataMember Attribute. I had just forgotten about that 
cheers, Bill
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
|
|
|
|
|
hi,
I have written the following code to export data from Excel
string tempPath = System.IO.Path.Combine(System.IO.Path.GetTempPath(), "Report.csv");
GView.SelectAllCells();
GView.ClipboardCopyMode = DataGridClipboardCopyMode.IncludeHeader;
ApplicationCommands.Copy.Execute(null, GView);
String result = (string)Clipboard.GetData(DataFormats.CommaSeparatedValue);
GView.UnselectAllCells();
System.IO.StreamWriter file1 = new System.IO.StreamWriter(tempPath);
file1.WriteLine(result);
file1.Close();
Excel.Application app = new Excel.Application();
Excel.Workbook workbook = app.Workbooks.Open(tempPath);
Excel.Worksheet ws = workbook.Worksheets[1];
I have 2 columns contain dates. both of them looks dd/MM/yyyy on the data grid which is correct.
once out on excel they change to american date format!?
the weired thing is, before the 13th of every month they are in american format. after the 13th they show UK format.
can some guru help me please
|
|
|
|
|
You need to format the cells in Excel.
|
|
|
|
|
I'm currently in a trade-school type program to become a .NET developer, and am in a 'project management' mini course that has a project that requires me and my teammates to gather 30 interviews with .NET developers. To simplify this, we have created a simple survey that asks the questions we need answered.
It would help us out a lot if you could give us some feedback! I promise this isn't spam! Here is a link to the survey (via Google Forms).
https://docs.google.com/forms/d/1A6c8YrD0zUZ-EEBeW4Coybum8dgwAXkFW-bZvg714Qc/viewform[^]
|
|
|
|
|
This has nothing to do with C#, and should be posted in the Lounge, not the programming forums.
|
|
|
|
|
Sorry about that, I didn't know where to post this and was unaware of the Lounge section under the community tab. I tried to delete this thread, but am unable to do so. Anyways, sorry for the error!
|
|
|
|
|
Hi there,
how can I change the text of my textbox, while the code is running?
I will change it when I click on the button "search", and while the programm is searching the text in my textbox should be "searching ..."
Can anyone help me please?
|
|
|
|
|
Um...
myTextBox.Text = "Searching...";
I'm sure that isn't the problem you are having, but I can't work out from that little what problem you want us to solve.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I think you are asking how you can use the TextBox as both the source of what to search for and, then, while searching, a kind of progress indicator.
If this is what you want, I'd argue against that because:
1. if the computer this runs on is not very powerful, you may delay the search.
2. if the computer this runs on is super-powerful, all you may see is a meaningless blur.
3. there is a traditional way of doing this: use either a progress-bar or a status-bar control.
There are good resources here on CP for using both progress-bar and/or status-bar with a process (like search) running in its own thread, which is desirable so that the main UI does not become frozen, and the user may have the opportunity to cancel the search, etc.
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
|
|
|
|
|
Okay but how can I show that it is searching?
|
|
|
|
|
Is there a way to change the speech recognition language, without installing language packs in windows or by installing them, but not changing the default language pack?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
