|
meeram395 wrote: We are storing our source code in VSS which is in UK server. Inorder to work locally in India, we need to connect to VPN, then to VSS to get the latest version of the code, which is in VS.Net 2008. Now, while opening the solution and also for checkout and checkin the files , and also getting the latest version to VSS, it is taking 2.5 - 3 hrs everyday which eats most of our working time.
Is it possible to write a windows service which will connect automatically to VSS and download the source code to our local system every day. Obviously each person VSS id and pwd will be different, even though the path will be same. We can proivde this as input config.
A Windows-service usually runs under a different context than the user; does it have access to SourceSafe?
I'm using batch-files to achieve something similar. We've got Tortoise, and downloading the latest code from the repository can be done over the commandline;
TortoiseProc.exe /command:update /path:"c:\stuff\code\" /closeonend:1 When done, the batch-file proceeds to build and executes the unit-tests. Gets executed every day by the Windows Task Scheduler.
SourceSafe supports the same[^].
Bastard Programmer from Hell 
|
|
|
|
|
Thank you for the reply. I was actually looking for a similar kind of functionality.
I will go through the same and come back to you.
Success is the good fortune that comes from aspiration, desperation, perspiration and inspiration.
|
|
|
|
|
A better solution would be to setup a mirror server in India which gets (and sends) a backup every night to the uk server. In this case the uk-server should be the master and the India-server slave.
We used a similar principle on a previous assigment and that worked quite well. This still ensures that you have the latest sources and can use the benefits of VSS, but keeps it all structured.
|
|
|
|
|
Since a few weeks my colleague is promoted to teamlead. That fact itself does not bother me, but he does try to impose a certain architectural design (SOA based) and motivates his decisions by saying it is the Microsoft way and read book X or Y, etc...
So I did read his indicated chapters (chapter 2 eg) and found most of it common sense really. However he made a sample solution based on his knowledge and creates a new project for each aspect of the application. That means that for one webservice you have a project for the services (svc files), the service contracts (the interfaces), the service implementation (svc.cs files), datacontracts, etc... it ends up in 10 - 20 projects per application. each business layer, dal component, etc should be redone for each application for independency  (the strange thing is, when I mentioned the GAC, a Microsoft way of working, the response was that that wasn't an option and didn't solve dll hell)
My problem lies in the fact that if indeed Microsoft supports such an idea (of dividing assemblies) why on Earth do they make it so hard in creating it (you start out by creating a solution with services and adding libraries as you go, but you need to actually MOVE the interfaces and implementation files to different projects. When all this is hooked up in TFS, you know that this could mess up the entire solution and above that you need to reference your projects all over the place to make it work. Personally I have a serious doubt this is a good way of working. If it really should be this way, why doesn't Visual Studio have this option or makes it so difficult to implement?
I'm for dividing logic and creating n-Tier applications, but personally I wouldn't start dividing a service project into servicecontracts, datacontracts, implementation, services assemblies.
Am I missing a point here, because this is pretty confusing. 
many thanks.
V.
|
|
|
|
|
You're not the only one finding it confusing.
I don't believe they'd use 20 different projects, it'd be mad.
Having 20 projects and changing the target framework would be quite a hassle.
|
|
|
|
|
my thoughts exactly, thanks for confirming I'm not the only one who's going banana's 
V.
|
|
|
|
|
V. wrote: Since a few weeks my colleague is promoted to teamlead. That fact itself does
not bother me, but he does try to impose a certain architectural design (SOA
based) and motivates his decisions by saying it is the Microsoft way and
read book X or Y, etc...
I am curious why a "team lead" is acting as an architect and/or boss.
As a development group if you want to create guidelines (code, architecture, process, whatever and etc.) then the development team, as a group, creates them, reviews them and approves them.
V. wrote: My problem lies in the fact that if indeed Microsoft supports such an idea (of
dividing assemblies) why on Earth do they make it so hard in creating it (you
start out by creating a solution with services and adding libraries as you go,
but you need to actually MOVE the interfaces and implementation files to
different projects. When all this is hooked up in TFS, you know that this could
mess up the entire solution and above that you need to reference your projects
all over the place to make it work. Personally I have a serious doubt this is a
good way of working. If it really should be this way, why doesn't Visual Studio
have this option or makes it so difficult to implement?
Your description doesn't make it clear what you find to be difficult.
If you have an existing application(s) and you need to completely restructure them to some other form then it is going to require work. And there isn't anyway to automate that.
On the other hand if you are creating new applications then at least for me working with different projects (and even solutions) and then combining them to create the final application is the only way I work (and in languages other than .Net as well.) Trivial apps can exist in a single space but with large apps I would expect tens of different divisions. Combining them is only relevant to the final app and for direct dependencies in the different parts. Understanding small parts is easier than understanding one large mass. I would suppose it also tends to keep the boundary layers more independent.
(Note however that I am not commenting on the MS methodology itself.)
|
|
|
|
|
jschell wrote: I am curious why a "team lead" is acting as an architect and/or boss.
That would be his job.
jschell wrote: As a development group if you want to create guidelines (code, architecture,
process, whatever and etc.) then the development team, as a group, creates them,
reviews them and approves them.
Nope, won't work; too many cooks: you'll never get agreement until someone says 'stop arguing and just get on with it' or casts the deciding vote. When I start a new project I dictate how it will happen, standards, etc., and that is how it goes: don't have time to dick about debating where comments should go or whether or not we use use regions or separate the project out into this bit and that bit. If someone comes to me with a good idea that can be easily retrofitted then I'm all for it otherwise won't happen till the next project some fool puts me in charge of.
I do, however, agree with much of your final paragraph though I will (usually) have a single solution broken down into logical parts with sub-solutions/projects as needs dictate.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
digital man wrote: That would be his job.
At the places where I have worked where the position "team lead" existed there were also other roles.
Such as "manager", "architect" and even "VP", etc.
Smaller shops might choose to call a manager a "team lead" but that wouldn't change the definition in my mind. To me a "team lead" provides technical direction. They are not in charge of personal management nor are they the final arbitrator.
A "manager" on the other hand is.
digital man wrote: Nope, won't work; too many cooks:
First let me clarify that my comments were made in the context of moving towards a formal process control system.
From that I have no idea what you mean. It certainly has worked for me in a number of different companies.
Matter of fact I believe there is a tenet of process control and perhaps even studies that back it up that process control will not work unless the participants are allowed to contribute to and approve the process. Without that then the point of process control will fail because it will end up as a paper pushing exercise.
digital man wrote: When I start a new project I dictate how it will happen, standards, etc., and that is how it goes: don't have time to dick about debating where comments should go or whether or not we use use regions or separate the project out into this bit and that bit.
Not sure what your point is.
Coding guidelines, which is what most of your comments seem to indicate you are referring to, is a trivial and ineffectual piece of most process control. It is often implemented because it is easy yet will have zero impact on actual productivity for an organization that does not have comprehensive process control.
And process control will not succeed at the project level. And that is backed by at least one study. It demonstrated that process control would not achieve success (something measurable) unless it was pushed down from the senior level (VP and higher).
|
|
|
|
|
I've worked on a Service project that had 14 projects. It worked well and the separation made sense. Definitely separating the functionality from the service itself makes a lot of sense. Why would you put yourself through the pain of testing a service if you could avoid it.
Just like everything, it needs to be considered in context. A simple service probably only needs 4 or 5 assemblies. A large, complex service could easily require 20 or more projects. To demand the same architecture across the board however would appear needless.
If I was to build even a small service I would have at least 4 projects.
Service project (wrapper to the Business logic)
Winforms test project (To test business logic and behaviour)
Business logic project
Deployment project
Personally I wouldn't have a problem but it sounds like your colleague may be getting a bit over-excited. Best he sticks to changing the colour of his waste paper basket for the first short while and get the team onside 
"You get that on the big jobs."
|
|
|
|
|
You've understood my rant  That was idd my issue. I would have done 4 or 5 seperate assemblies as well based on the tasks they perform, especially since most services we will write will perform simple tasks.
V.
|
|
|
|
|
V. wrote: and motivates his decisions by saying it is the Microsoft way and read book X or Y, etc...
I do like to re-use a lot of their work, patterns and idea's from MSDN.
V. wrote: and found most of it common sense really.
Sounds good.
V. wrote: creates a new project for each aspect of the application
What would common sense do?
V. wrote: strange thing is, when I mentioned the GAC, a Microsoft way of working, the response was that that wasn't an option and didn't solve dll hell)
..but it it the Microsoft way, exactly with that title as a claim. From MSDN;
Simplifying Deployment and Solving DLL Hell with the .NET Framework[^]
It's kinda cool to list different versions of a "save"-plugin that you found and have the user select the version to save with
Bastard Programmer from Hell
|
|
|
|
|
Eddy Vluggen wrote: What would common sense do?
lol, for me common sense would be to avoid complicating things unnecessary. His idea is to work with "enterprise" applications. Performance is not his main concern (read, not important).
I can agree on an "enterprise" application if it is a large one, but for a simple module (most of them are) I'm not seeing the added value.
Looks to me like we're using a bazooka to kill the mosquito 
V.
|
|
|
|
|
Or wanting everything to be done the same way, every time, whether it's a large or small project.
I guess that has its points.
|
|
|
|
|
That's what he gives as a reason, but IMHO he just wants to put his mark on the team/company.
V.
|
|
|
|
|
Hey!
I'm just doing some research for the next project.
Can you provide me some imformation about Data Fusion? Is there a general approach on how to handle the data and how to combine it to get homogeneous?
regards
Torsten
I never finish anyth...
|
|
|
|
|
|
THAT is what I was searching for - +5 & a big thank you
regards
Torsten
I never finish anyth...
|
|
|
|
|
Hi! Can somebody explain to me why we use a Base interface as a return type in a Factory interface?
Second question in concerned with the code in Main.
I figured out that Factory factory = new ConcreteFactory2() is a reference to the implementation of a ConcreteFactory2 of GetObject() method. What is the next line?
Thanks. I appreciate your help!
abstractfactory
{
class Program
{
static void Main(string[] args)
{
Factory factory = new ConcreteFactory2();
Base obj = factory.GetObject();
obj.DoIt();
}
}
}
interface Factory
{
Base GetObject();
}
class ConcreteFactory1 :Factory
{
public Base GetObject()
{
return new Derived1(); // do we return an instance of derived 1 interface?
}
}
class ConcreteFactory2 : Factory
{
public Base GetObject()
{
return new Derived2();
}
}
interface Base
{
void DoIt();
}
class Derived1 : Base
{
public void DoIt()
{
Console .WriteLine("Derived 1 method");
}
}
class Derived2 : Base
{
public void DoIt()
{
Console.WriteLine("Derived 2 method");
}
}
|
|
|
|
|
Can somebody help me with this?
It's for my colledge presentation and I have to figure it out.
Thanks!
|
|
|
|
|
The abstract factory pattern is explained fairly well here:
http://en.wikipedia.org/wiki/Abstract_factory_pattern[^]
It returns Base as the object type because different factories will return different types of object, but those objects must have something in common.
Imagine a VehicleFactory interface with a method GetVehicle that returns a Vehicle. One type of VehicleFactory might be a PetrolVehicleFactory, that returns vehicles that run on petrol. Another might be an ElectricVehicleFactory that returns electric-powered vehicles. Both of these return type Vehicle, so I can use the factories interchangeably without having to worry about whether it is an ElectricVehicle or a PetrolVehicle that is being handed to me.
VehicleFactory myFactory = new PetrolVehicleFactory();
Vehicle myVehicle = myFactory.GetVehicle();
myVehicle.Start();
myVehicle.DriveOffIntoTheSunset();
I can swap PetrolVehicleFactory for ElectricVehicleFactory, and nothing else in my application needs to be changed:
VehicleFactory myFactory = new ElectricVehicleFactory();
Vehicle myVehicle = myFactory.GetVehicle();
myVehicle.Start();
myVehicle.DriveOffIntoTheSunset();
As long as ElectricVehicle and PetrolVehicle both do what a Vehicle is supposed to do, I don't care what exact type of Vehicle the factory gives me. I just want a Vehicle so that I can drive off into the sunset. It's the factory's responsibility to know what type of Vehicle to make and how to make it.
|
|
|
|
|
A nice, clear and concise explanation; have a 5. 
The best things in life are not things.
|
|
|
|
|
Thank you for your explanation. It's a lot clearer.
Could you just explain the client code?
I mean is Vehicle myVehicle = myFactory.GetVehicle();
a reference to GetVehicle?
Thanks
|
|
|
|
|
The variable myVehicle holds a reference to the Vehicle object returned from the GetVehicle() method.
|
|
|
|
|
Thank you for the answer!
I did well at my presentation! 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
