We Keep Coding

specifying events as files to live on Core project instead of service project

In my solution I have 3 projects
MyProject.Core
MyProject.Services.DataImporter
Myproject.Services.Cars
Both DataImporter and Cars projects are referencing MyProject.Core project.
I have an event (DataImportFinishedEvent) which is emmited by DataImporter service.
Services.Cars is subscribed to this event and potentially more services later.
With my current approach, I have this event (DataImportFinishedEvent) as a file created
on both services.
Since both services are referencing Core project should I move this event to the Core project? Doing so will have file on one location only.
Is this a good microservice practice?

In general have common projects or libraries is not a good practice in microservices because this way you are coupling the develop and deploy of both services, so when you make a change in the common project, you have to change and deploy the two other microservices.
In the case of the event, the best way is to have different events in both of the services. This not necessarily means that they have to be duplicated. In the producer side you must have an event with all the information needed by any of the potential consumers and in the consumer side you must have an event with the information needed by that service, that can be less.
This way, you decouple the two services and if tomorrow the consumer service need other information provided by the producer you only have to change the consumer side and vice-versa
One way to think about it is when you are consuming a third party api that you are not controlling, you build your own response object with the data provided by the api that you need and this object is different that the one used by the api.

Communication between servicestack and mvc app without references circular dependency

I`ve already asked for something here Update view in response to web service requests AND I got the answer for most important question however I have another one related to this.
I have 2 projects in my solution (actually more but others are irrelevant in this case) - ServiceStack web services which is library type of project and MVC application. I would like to use mvc app's functions or variables (so share MVC project's memory with web service). I can do this if I move web services classes into the main project but I would like to keep it separated. I, of course, already added web service's project reference into main project (MVC) but I can't add main project references info web services project because it says that it cannot be done because it would result in circular dependencies, which isn't anything strange.
What's the best solution to either share memory between these projects or provide a communication channel between them. I don't want to, for example, make requests to my controller's public methods. I know that when you face circular dependencies it means you did something wrong while designing a solution but in this case these 2 projects are separated only to separate web services classes from the main project.

You should add a third project that includes all the common classes you need to use from both your projects.

Look at the MVC Integration and ServiceStack Integration wiki pages for docs on integrating between ServiceStack and MVC. e.g. if your MVC Controller inherits ServiceStackController you'll have access to ServiceStack dependencies and IOC to resolve any registered dependencies. You'll also be able to call ServiceStack Services directly.

Namespaces and type resolution in C# solutions with webservices

This might get a little convoluted so please let me know if you need clarification.
I have a solution which contains the following projects
Project A - WPF application
Project B - ASP.NET application (with exposed webservices)
Project C - Class Library
Both project A and project B reference types that are located in project C, but more importantly project A makes webservice calls to project B using types located in project C.
The problem I am running into is it appears that when making webservice calls I have no way of referencing the types located in project C directly but rather need to use the types as exposed by the webservice.
Now the basic idea of why this is done I understand (obviously typically the consumer of your webservice would only have the WSDL to go from) however in my case this is an internal application (which is part of a single solution) so this is not a concern.
The biggest problem I see with continuing this approach is that any updates to the types in project C will need to be reflected in project B and then "refreshed" in project A. This seems pretty nasty to me. Surely there is a smoother path?
Am I wrong? What is a typical approach to this issue?

You may be a little confused here.
The types in Project C and the types you see when you add a reference to your web service are different.
When you added the Web Service reference. Visual Studio used svcutil.exe, read metadata from your web service (I'm assuming .asmx?) and then created proxy classes for you.
Check the types for the Web Service (they will obviously have the same names). Put your cursor on them and pres F12. It'll take you to some designer generated code.
So there is no real workaround as such. When you update your types in Project C and then Update your web services in Project B . You will have to Update Service Reference from Project A Which again uses svcutil.exe and regenerates all your proxies.
Also, this is the same way WCF Services work too.

#giddy is correct - the types exposed by the web service are different to the types contained in Project C - even though their definition may be identical. The web service exposes type information via a wsdl, which Visual Studio uses to generate proxy types.
There is a way around this - you can create an interface which declares all the methods in the web service class, and include it in your shared library. You can then skip the "Add service reference" process, and create the web service proxy with code (you will not need the proxy classes, as you use the classes in the shared library).
Either way, if you make a change to your data transfer objects or the web service class, you will need to update the client by either by requerying the wsdl using "refresh service reference", or by copying the shared library over.

Building web services and updating client application with MSBuild

I have a solution that contains two projects (web services and client application).
When i built solution, i always need to update Web References manually (web service's proxies).
Is there any way to do it automatically with MSBuild?

You should be able to use svcutil.exe to create the proxy for you. You just have to get all the parameters right.

You could share contracts via a Contracts DLL if that makes sense for you from a design perspective (you'll be breaking loose coupling) and you have the tooling (the WCF wizards make it easier to do)

Best Project Template to use for Classic Web Service

I'm going to create a new PayPal project. Should I just create a regular Class Library project then add the reference to the WSDL? We are not using WCF. I just want to know what the best project type / template I should use if I'm going to share this project with lets say another WAP web project. I simply want to create wrappers for some of the WSDL that we'll be using in part of the PayPal API.

Yes a class library project seems the right thing to use if you're wrapping the code that consumes a web service.
Unless it's going to be tiny (say, just one class) in which case you might want to include it in an existing common project that is already used by both of your consuming projects, just to keep everything a little simpler.