Visual Studio: Testing and deployment of files
When doing unit testing in VS (2008) the default is as follows:
VS copies the compiled and all referenced assemblies to a folder named Testresults in a subfolder called something like:
username_pcname currentdatetime
If you have extra files, like for instance wse3policy.config, you need to tell vs to copy these files to the test folder, or else your tests will fail.
One way of doing it is by adding an attribute [DeploymentItem(path)] to your tests.
This will copy the files to the out folder.
You can also use menu Test - Edit Test Run configuration and from within there select Deployment and select all the files you need for your tests to run.
But today I found a third option:
Turn off Deployment.
In the same menu you selected files, you can uncheck the Deployment checkbox, and by doing this disable the entire copy assemblies and related files to a folder I really don't want issue… :)
This saves you the trouble of selecting which files you need for your tests,
it also makes your tests run a bit faster, as you don't have to wait for vs to create folders and copy all files to it for each run.
Be aware that this disables code coverage results, untill you either enable deployment again, or if you go into code coverage you will be told that to do this you need it enabled, and given the option to turn it back on.
Also note that you need to do this pr solution, as MS in their wisdom has made deployment the default, with no way to select a new default afaik.
If you have a lot of tests in your solution there is another option that can help speed things up.
Test Tools menu within Tools - Options, select Test Project and Disable background discovery of test.
This can help things speed along.
rgds
Henri
Posted via email from Henris blogg
c#/Linq: Remove duplicates in a list, using group and orderby in linq
I had some really ugly code to remove duplicates in a list.
Here's my take at doing the same with linq and grouping.
Probably could be improved, but I like this way better then the ugly original.
I find it really easy to read too.
Because of the way the original was constructed, I used a couple of tries to get to this.
My first attempt used the same way of thinking as the original,
and that wasn't much prettier then the old c# 2.0 code.
private static List<NytegningAktoerRetur> GetSisteTilbudPåSammeNrLinq(List<NytegningAktoerRetur> liste)
{
var MidlertidigNrTilbud = from t in liste
group t by t.MidlertidigForsNr;
var FinListe = new List<NytegningAktoerRetur>();
foreach (var midlert in MidlertidigNrTilbud)
{
if (midlert.Count() > 1)
{
//Finn siste
var t = from tilbud in midlert
orderby FinnOppgaveID(tilbud.TilbudID) descending, tilbud.DatoRegistrert descending
select tilbud;
FinListe.Add(t.First());
}
else
FinListe.Add(midlert.First());
}
return FinListe;
}
The original is here for warning purposes only :)
Don't try this at home…:
private static void GetSisteTilbudPåSammeNr(FinnTilbudAktoerReturMelding retur, bool InkluderStartedeTilbud)
{
Dictionary<string, FinnTilbudHolder> liste = new Dictionary<string, FinnTilbudHolder>();
List<string> sakstartet = new List<string>();
FinnTilbudHolder h;
foreach (NytegningAktoerRetur r in retur.TilbudsListe)
{
int OppgaveID = FinnOppgaveID(r.TilbudID);
h = new FinnTilbudHolder();
h.Tilbud = r;
h.OppgaveID = OppgaveID;
//finn nyeste
if (liste.ContainsKey(h.Tilbud.MidlertidigForsNr))
{
//finn siste basert på oppgaveid
FinnTilbudHolder org = liste[h.Tilbud.MidlertidigForsNr];
if (OppgaveID > org.OppgaveID)
{ //denne (r) er nyest, skal erstatte org i listen
liste[h.Tilbud.MidlertidigForsNr] = h;
}
else if (org.OppgaveID > OppgaveID) //org er nyest basert på oppgaveid
{
//beholder org
}
else if (org.OppgaveID == 0 && OppgaveID == 0) //ingen oppgaveid angitt, returner nyeste på dato
{
//hvis nyerere "vinner" den (r), ellers ingen endring
if (h.Tilbud.DatoRegistrert > org.Tilbud.DatoRegistrert)
liste[h.Tilbud.MidlertidigForsNr] = h;
}
}
else
{
liste.Add(h.Tilbud.MidlertidigForsNr, h);
}
//husk de som har startet sak
if (!String.IsNullOrEmpty(h.Tilbud.Saksnr)) sakstartet.Add(h.Tilbud.MidlertidigForsNr);
}
if (!InkluderStartedeTilbud)
{
//fjern de som har startet sak
foreach (string forsnr in sakstartet)
{
liste.Remove(forsnr);
}
}
List<NytegningAktoerRetur> l = new List<NytegningAktoerRetur>();
foreach (FinnTilbudHolder f in liste.Values)
{
l.Add(f.Tilbud);
}
retur.TilbudsListe.Clear();
retur.TilbudsListe.AddRange(l.ToArray());
}
That's it for the old retarted ehh I mean retired code :)
To be fair, I also moved the code of InkluderStartedeTilbud out of this function, it goes like this:
if (!param.InkluderStartedeTilbud)
{
//Fjern startede tilbud
retur.TilbudsListe.RemoveAll(g => !String.IsNullOrEmpty(g.Saksnr));
}
I just moved it out to make the function more clear.
The refactoring to linq also allowed me to remove the FinnTilbudHolder class, as it was just used to keep record of each records id,
because it was an expensive operation to get it (ws call).
In addition and it was now easy to just get the id when I knew that there was more then one record with the same number.
I could (should) have done that with the old code too, but now it was real easy to do because of the grouping and count.
I'm happy with the new and refactored linq version, and the easy grouping, counting and sorting in linq.
Rgds
HM
Posted via email from Henris blogg
C#/Linq : Filter a list based on From/ To dates (and IENUMERABLE to LIST)
Filter my List (retur.Tilbudsliste)
based on input of from and to-dates
if (param.FromDato > DateTime.MinValue || param.ToDate > DateTime.MinValue)
{
//filter on date
var filtrert = from t in retur.TilbudsListe
where t.DateRegistered >= param.FromDate &&
(param.ToDate == DateTime.MinValue || t.DateRegistered <= param.ToDate)
select t;
retur.TilbudsListe = filtrert.ToList();
}
The result filtrert is of type Ienumerable, and is then cast to a list with:
retur.TilbudsListe = filtrert.ToList();
Note that with the check on DateTime.Minvalue we've made both inputs optional,
allowing us to specify none, one or both params.
Posted via email from Henris blogg
Team Foundation server: policy error
When checking in to Team Foundation Server I got error:
TF10139
with several errors regarding policies, including:
Internal error in changeset comments policy
Solution:
Modify my Team Foundation Server Power Tools-installation
and select the Check-In Policy Pack
Team Foundation Server Power Tools can be downloaded from here: http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx
As I already have it installed I'm not sure if you have to select Custom etc when installing, but you should verify that this is selected when installing, or modify afterwards as I just did. :)
That's it.
Have a nice weekend.
Rgds
Henri
Posted via email from Henris blogg
c#: Changing a value in a dictionary in a foreach
I was trying to loop through a dictionary,
update it's value if a certain condition was met,
if not remove the item from the dictionary.
(Seems I have done something lke this before, but that's why I blog it, so I can remember next time… :))
Here's my first attempt:
private void FindEditedFieldsNotWorking(Dictionary<string, string> dictionary, Control ctrl)
{
foreach (KeyValuePair<string,string> kvp in dictionary)
{
CheckBox c = ctrl.Controls["chk" + kvp.Key] as CheckBox;
if (c != null && c.Checked)
{
dictionary[kvp.Key] = ctrl.Controls[kvp.Key].Text;
}
else
dictionary.Remove(kvp.Key);
}
}
It compiles ok and seems ok.
Might have a misgiving with removing the item in a loop, but hey it's worth a shot..
When running this I got an exception something like
"Collection was modified; enumeration operation may not execute."
My first thought was that my dictionary.Remove was the culprit, so I put a breakpoint there.
But that was not the case (although that is not supported either in this loop)
It seems that I can't actually change the freakin' value within my foreach loop…!
So I tried the same but this time using just the keys in the loop:
private void FindEditedFieldsNotWorkingEither(Dictionary<string, string> dictionary, Control ctrl)
{
foreach (string Key in dictionary.Keys)
{
CheckBox c = ctrl.Controls["chk" + Key] as CheckBox;
if (c != null && c.Checked)
{
dictionary[Key] = ctrl.Controls[Key].Text;
}
else
dictionary.Remove(Key);
}
}
Still no go, same error.
Eventually I read a little bit about this using google and found that I couldn't do any changes while enumerating.
Here are some links I used:
http://stackoverflow.com/questions/1070766/editing-dictionary-values-in-a-foreach-loop
Seems like a bad design decision has made this a problem for many ppl.
The incling is probably the implisit add functionality when doing dict[key]=value; when key is not existing.
Anyways we have to get around this somehow.
The solution I thought was nicest when I couldn't use the "logic" solution is:
.Net 2.0
private void FindEditedFieldsWorking(Dictionary<string, string> dictionary, Control ctrl)
{
List<string> keys = new List<string>(dictionary.Keys);
foreach (string key in keys)
{
CheckBox c = ctrl.Controls["chk" + key] as CheckBox;
if (c != null && c.Checked)
{
dictionary[key] = ctrl.Controls[key].Text;
}
else
dictionary.Remove(key);
}
}
Almost as nice as the first version, and with the added premium that dictionary.Remove won't be a problem.
Or if you're running .Net 3.0 or higher you could just do this:
private void FindEditedFieldsWorking(Dictionary<string, string> dictionary, Control ctrl)
{
foreach (var key in dictionary.Keys.ToList())
{
CheckBox c = ctrl.Controls["chk" + key] as CheckBox;
if (c != null && c.Checked)
{
dictionary[key] = ctrl.Controls[key].Text;
}
else
dictionary.Remove(key);
}
}
where the ToList does the same as our 2.0 solution, namely creating a temp list to hold the keys.
Nice solution on a not so nice problem.
Hope this helps someone,
it will help me next time anyways :)
Regards
Henri Merkesdal
MERIT
Posted via email from Henris blogg
Posts
1 comment :
Post a Comment