I've got a client-server (with transpiled js and rpc calls to server) application with websharper, and it runs perfectly fine.
Now I need a single javascript file for another site (a WordPress app) and from this script, I'd like to access to everything public (non protected rpc) I made in my former client-server application.
The ideal would be to be able to use the websharper SPA template and "link" to the client-server project.
I've got two problems:
- First, rpc signature are encoded with a hash which seems to be local to the app (no simple way to reproduct this hash outside it)
- Second, apparently there is no way to actually link the generated dll from the client-server app into the new SPA template and use the exported rpc method signatures for the SPA.
Am I missing something, how to make this work ?
Regards,
Referencing your client-server application from your SPA should work just fine; you just need to make sure that it points to the right URL by calling the following somewhere in your SPA:
WebSharper.Remoting.EndPoint <- "http://your-client-server-application's-url"
Related
I'm following this example for a queued hosted service to add this to an ASP.NET Core application, and it's not clear to me where StartMonitorLoop should be called. I ended up modifying it to be EnsureMonitorLoop, added a check so that it's the call to Task.Run is only made once, added a MonitorLoop parameter to constructor for my API controller, and called EnsureMonitorLoop from there. It smells kind of funny to me that the API controller constructor should be kicking off monitoring the queue. The example Program.cs seems is very different from the one generated for me by Visual Studio. Mine uses the WebHost.CreateDefaultBuilder(args).UseStartup<Startup> approach. That is where they call StartMonitorLoop.
Where is the correct place to call StartMonitorLoop, and why? Thanks!
The docs aren't super clear here, but MonitorLoop is not actually part of this. It's an example service for use in a console app, simply to demonstrate how the queued background worker works. You can take some inspiration from this class for your app, but the concept of StartMonitorLoop doesn't apply to ASP.NET Core at all.
Just to be a bit more clear: in actual practice you would inject IBackgroundTaskQueue into a controller class, for example, and then add some task to that, just like MonitorLoop does (without all the key input jazz). You wouldn't actually have MonitorLoop or anything like it though.
I'm trying to create a Web API project and a client-side web project, where the web project can access the API via ajax. Currently my project looks like this:
I saw this answer on here: Setting app a separate Web API project and ASP.NET app, which explains how the project url can be set to localhost:[port]/api.
But for ASP.NET 5 projects, the properties only have 3 tabs (as opposed to the several found in ASP.NET 4 projects):
What I'm wondering is:
Do I have to set this option somewhere else? (i.e project.json)
How would this work when I publish? Ideally I'd want [websiteURL]/api to serve up my API, whereas that link explicitly put localhost:8080.
Is having these as two projects a good idea? I could easily put API and web in the same project, but I like the separation of client-side and server-side logic.
Any help would be appreciated!
First Point:
Generally speaking in ASP.NET 5, the routing defaults are very good and should work out of the box without much in the way of configuration. You can use configuration and/or attribute based routing in your application (with a detailed overview of both here), although my personal preference is for the attributed approach. Provided you have the following line in your Startup.cs file (which you should have in a new project):
app.UseMvc();
you should be able to route requests to your api controllers in the fashion required (i.e. "/api/...") simply by using [Route] attributes as below (example taken from a standard generated ASP.NET 5 Web API application)
[Route("api/[controller]")]
public class ValuesController : Controller
{
[HttpGet]
public IEnumerable<string> Get()
{
return new string[] { "value1", "value2" };
}
}
The above example will route any GET request made to "/api/values".
While this approach can be used to handle requests made to your api, in order to deliver the files needed for your front end javascript application/single page app, you will need to enable static file serving. If you add the following to the Configure method in your Startup.cs class:
app.UseStaticFiles();
this will allow your application to serve those static files - by default, these are served from the ‘wwwroot’ folder, although this can be changed in the project.json file if required. The files needed for your front end app should then be added to this folder. A tutorial on serving static files can be found here.
Second Point:
In my experience this will not be an issue when you publish your website - provided your server is set up correctly, you will not need to include the port when making a request - navigating to [yourwebsitename]/api/... will suffice.
Third point:
In my opinion this entirely depends on how large the project is likely to grow, although preference and opinion will vary from developer to developer. Generally speaking, if the project will remain small in scope then keeping both in a single project is perfectly ok, as unnecessary complexity is reduced. However it is also very useful as you have pointed out, to maintain a separation of concerns between projects. So aside from the organisational advantage of your approach, the respective dependencies of the two projects are/will be kept separate also.
I have a working SignalR application, my global.asax.cs does all the usual MapHubs() etc, and I'm using a custom IAssemblyLocator which also loads in-memory assemblies as well as referenced assemblies. The two hubs I have are created at runtime in in-memory assemblies, and this works fine - hubs can push messages to clients etc.
At some point after the application has started, I want to add another hub at run time which will sit in it's own in-memory assembly, and make it appear in the signalr/hubs/ file.
How do I do this?
Calling MapHubs again results in an error because I already have the route defined. Removing the route (which I've only managed to do using RouteTable.Routes.Remove(RouteTable.Routes[0]) so far, and obviously isn't ideal) doesn't seem to work.
Is there a nice way to do this?
Use the alternate syntax instead of using the static signalr/hubs file since it will never update:
http://www.asp.net/signalr/overview/hubs-api/hubs-api-guide-javascript-client#genproxy
Is there some sort of configuration settings in FlashBuilder 4.5 where you can easily switch between webservice urls? Right now I have to delete and recreate the web service every time I switch from local to production and vice versa.
The need/requirement is this – Since I work in a startup, we keep changing servers, and their IP addresses. And being a service oriented application – I need to be able to edit the webservice endpoints in my Flex application in a easy manner every time this happens.
My Solution for this -
Assumption is that my webservice endpoint looks like this -
http:////ListAllServices/
1) Create a file config.xml in a folder named “settings” that sits in the root folder of your Flex application – outside the “src” folder. And the config.xml will be a simple xml file of the following format -
localhostTestFlexApp
At the end of this exercise the directory structure of your flex source code will look like this -
flex_src(root of the source code)
-com(some source folder)
–testapp
—view
—
-images
-settings
–config.xml
-appName.mxml
2) Now in your application code, setup a HTTPService object either in mxml or action script. Set the url of that object to this value- “settings/config.xml” – And the above xml fiel containing the current settings will be loaded into memory .
Now you can store these values in a singleton object and construct your Webservice call at runtime.
And whenever you want to move this to a new server in production, edit the tag of your config.xml and you should be good to go.
And this can be automated as well via the EnvGen ant task.
This is not the best way but yes it is very helpful while switching among servers.
Alrighty... The way I was doing it before in fact worked. The problem was browser caching.
For the benefit of others I modified the subsclass for the generated service and replace the wsdl variable with whatever endpoint I need.
We have a series of web services that live in different environments (dev/qa/staging/production) that are accessed from a web application, a web site, and other services. There are a few different service areas as well. So for production, we have services on four different boxes.
We conquered the db connection string issue by checking the hostname in global.asax and setting some application wide settings based on that hostname. There is a config.xml that is in source control that list the various hostnames and what settings they should get.
However, we haven't found an elegant solution for web services. What we have done so far is add references to all the environments to the projects and add several using statements to the files that use the services. When we checkout the project, we uncomment the appropriate using statement for the environment we're in.
It looks something like this:
// Development
// using com.tracking-services.dev
// using com.upload-services.dev
// QA
// using com.tracking-services.qa
// using com.upload-services.qa
// Production
// using com.tracking-services.www
// using com.upload-services.www
Obviously as we use web services more and more this technique will get more and more burdensome.
I have considered putting the namespaces into web.config.dev, web.config.qa, etc and swapping them out on application start in global.asax. I don't think that will work because by the time global.asax is run the compilation is already done and the web.config changes won't have much effect.
Since the "best practices" include using web services for data access, I'm hoping this is not a unique problem and someone has already come up with a solution.
Or are we going about this whole thing wrong?
Edit:
These are asmx web services. There is no url referenced in the web.config that I can find.
Make one reference and use configuration to switch the target urls as appropriate. No reason to have separate proxies at all.