Develop Reference

Asp.net web API 2 separation Of Web client and web server development

Our web application is developed by 2 teams. One team works on the client side, with it's own Branch for development, and the other works on the server side, also with it's own development branch. The client and the server are running separately, each one as a website on a different port. The websites are hosted over IIS Express during development, and in production they will run over IIS.
Our ideal situation is that each team can develop completely separately and whenever a develop session is over, both teams merge their change-set to a common Branch in order to integrate, than each team merges back to their development branch, and continues.
In order for a full separation, We have x2 SERVER projects, one to handle the real HTTP requests and another one, a "Stub server" Which responses to all the clients HTTP requests with default values, just in order so that the Client side team can test their code without being dependent on the functionality of the server.
The problem is that both the "Stub server" and the real server and using the same Port which the Client side project is directed to.
This causes many annoying mistakes (mostly for the Server side team) of running the application with the "Stub server" instead of the real one, during reviews, tests etc. The only solution for us is to manually create a virtual directory for the real web server project every time before running / or after finding out we were running the wrong server.
Is there a smarter solution to overcome this annoying problem? That would improve our lives!
If anything I said was foolish / not clear please correct me (I'm new to this), or ask for more details, I'll be glad!
Thanks for helpers!

I believe your problem is more related to build automation then server configuration. You should really keep the stub server and the real server into separate ports, and change that port during some kind of build process of your client.
If you are using AngularJS, then I suggest you to create steps into the build process of your client application using common tools like gulp or grunt. You could create build processes that will set a global variable or modify a constant (e.g. the API endpoint) and name them local testing (pointing your client to the stub server) and integration (for the real server).
Please note that you can easily integrate those build processes into Visual Studio, making them part of your global debug/build process.
Here it is a simple gulp task useful for replacing text inside any file: https://www.npmjs.com/package/gulp-replace

Creating a web based device config utility

I want to develop web based configuration utility for WIN CE 6.0 device. This webpage is expected to configure/access/modify device's registry settings, reboot device etc. WIN CE Device has a webserver running on it. I am clueless about how to start.
Suggest some way to modify registry values using webpage.

Take a look at the source code for the default web admin module. Fair warning, it's ISAPI, it's near impossible to debug with anything but MessageBox calls and it has to be done in C++. But it is free.
The source is installed with Platform Builder and ends up on your dev machine at
%WINCEROOT%\PUBLIC\SERVERS\OAK\SAMPLES\HTTP\WEBADMIN
Another free option would be to create and install a COM object (written in C++,. most likely with ATL) on the target. Your web pages could then create an instance of that object and use it to interact with the device using the built-in "classic" ASP server. Installing the COM object on already-deployed devices or devices where you don't create the OS is going to be a large support challenge. Debugging these objects is not fun (though slightly easier than ISAPI if you build a separate test loader app). Also be aware that the built-in ASP server supports only a very scaled-back subset of ASP 3.0 (which is obsolete to begin with).
All of the web-based device admin we've ever done (and we've been doing it for a decade) has been through the Padarn Web Server, which uses C# following a subset of the IIS object model. It's a commercial product, so it's not free, and for full disclosure it's a product that we created (because I felt the built-in option is so bad) and sell.

Local or remote programmatic execution of an SSIS package?

I have an SSIS package on my desktop, which I registered to Integration Services on a remote box.
The service I am going to use to execute the SSIS package I have registered on that box will be hosted on an app server else where in the network and will be making a call to execute the package.
Before I begin writing the final code to make this happen, I have come to a fork in the road on how to proceed:
MSDN has two articles on how to programatically access an SSIS package.
One article is titled: Running an SSIS Package Programmatically on a Remote Computer
The other article is titled: Running an SSIS Package Programmatically on a Local Computer
I have read both, but its confusing to me how they are using the terms Local and Remote. \
It seems the Local Article says that even if you have a package on another computer, with this implementation it gets run on your local machine.
With the Remote Article it seems like the package will only execute if the service that calls it is running on the same machine. To me, this seems like a true "local" implementation.
Which article / implementation would I need to follow in order execute a package as I described above?
Again, I am running a Windows Service on my workstation and trying to execute a package that is registered on another. To me, this seems to be the Remote route, but I don't know.
Help! Thanks.

Yes, you are right, it's a little bit confusing. You should read this blog entry as well. Michael Entin posted a whole bunch of opportunities. He is focusing on the local/remote execution ways of running packages.
However, there is another way, through PowerShell.
In your case, I think it will not be good if you implement a web service on the application server. If you use SMO in this web service, the package will executed on the same server, which don't have SSIS installed, I guess. So this will fail. If you install your web service on database server, it'll be ok. But this way, you should open a specific port on this server. (Ok, I know if you implement the PowerShell way, there two ports have to be opened.)
Update
I try to explain on a little example. Say you developed a WinForms application in which you have a task that will launch an SSIS package. You installed this app on your application server. There is another server with SQL Server (and SSIS also) installed. This is your database server. When we talk about local/remote package execution we watch the system from the point of view of the WinForms app. Because the SSIS component is installed on the remote server (i.e. database server), you can only use the remote execution. So your windows service should be implemented on the database server. Another question might be how to reach this windows service. In the remote execution article you previously mentioned are two different ways of implementing remote execution: through SQL Server Agent job, and through a web service. The third option would be PowerShell as I mentioned above.
Of course from the point of view of the job or web service it is a true local implementation, as you wrote. But the MSDN articles focuses on your application on your application server (WinForms app for instance).

How do i update an application after pusblishing it in visual studio

I published an application,when publishing it i checked that the application should check for updates-now how do i make it realy check for updates-where should i put the new files and in which format?

You'll need it on some kind of Web server.
I would imigine that you also want some authentication so that only the application it self can gain access to the new version of the software.

I'm going to assume you mean you are using CLickOnce as the installer. If you want the app to check for updates every time it is ran you need to publish to a location all the apps can see. If this is an internal app I believe a network share will do. If not then you need to publish to a web server or ftp server.

You can use ClickOnce as nportelli mentioned above, or you can use a 3rd party utility to do the heavy lifting for you.
I wrote an open-source library to do just that transparently - including an external update application to do the actual cold update. See http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/
The code is at http://github.com/synhershko/NAppUpdate (Licensed under the Apache 2.0 license)

Questions related to Installing Silverlight on Mac

We are planning to develop a Silverlight 'cross platform' application, that is expected to run on both Windows and Mac with elevated permissions. Mono alone is not an option, as the application requires Silverlight specific video features, supported only in SL 4.0
So, here are some considerations.
1 - The 'Application', should interface with a local database (outside Isolated storage)
2 - The application should be able to talk to native libraries for performing some DVD IO operations.
3 - It has to be installed via a custom installer, much like a desktop app
We are trying to identify the best way to to satisfy the requirements, if possible, with a common code base, probably using SQLLite for the database.
In Windows, things are straight forward. You can use sllauncher to install the XAP with elevated permissions, and you can access the SQLLite and other system level operations via probably a COM layer. Not a big deal.
But how to implement interfacing with SQLLite and system level libraries in Mac? Is there a documented/undocumented way to interface with Mac libraries from Silverlight (Mac)? I think no. One option might be to use Mono's XSP web server, and run an ASP.NET site from the local machine, and host the XAP locally, and then implement a handshake with the ASP.NET code running via Mono/XSP, and then do the interfacing from there.
Another option will be to host the Silverlight in the Mono's Winforms browser control (I still need to see if this is possible), and then do the talking between Mono Winforms browser and Silverlight via HTML DOM.
Both are not straight forward options in Mac.
I highly appreciate any inputs you can provide to achieve the objectives in a better way.

Part of the solution could be to define an interface on your database. In windows you could choose to talk directly to it, and for mac you write a soap server. Your silverlight app should be allowed to talk to that. You can implement the soap server in mono, then you have one language all way....

I don't believe the Winforms browser control works on Mac, but you could try MonoMac instead.