From within FlexBuilder3, I can go to "Data/Manage Web Services..." select a web service, and click "Update" to ensure that my code and the server are in sync. How do I automate this so that each time I build, the automatically generated web service code is regenerated?
If the server interface changes during development but my code doesn't, it won't work anyway - I'd rather have a compilation error than a runtime error I had to track down to a changed web service interface.
Unfortunately you can not update a web service at build time. The update is part of the wizard and is not implemented as a separate action to be called on demand.
One suggestion I have is to go in the project properties and inside the Build panel add as a new builder a program. You will have to create this program that checks each time the project is build that the WSDL file did not change. It is a little bit complicated but if you are working on a project that relies on a web service that is under heavy development it might save you a lot of time.
Related
Whelp, I avoided it as long as possible, but the time has finally come to make some changes to some ancient VB6 code. I'm a recent college grad so I was hoping to stay away from this code that is almost as old as I am.
The DLL is compiled in a local installation of VB6 and deployed via Component Services. That component is then called by VBScript in a Classic ASP application running on a windows 2003 Server.
I've tried just about everything to debug this code using the VB6 debugger, but I can't get it to work. I've compiled the DLL to the same location that Component Services has it deployed to (a random folder on a non-system drive), and set binary compatibility to that same DLL. Each class file has instancing set to MultiUse and MTSTransactionMode set to '1 - NoTransactions.' The component works fine until I attach the debugger, then I get 'ActiveX component can't create object' when trying to instantiate the object. If I detach the debugger, it works again.
I noticed that in Component Services when I attach the debugger, the DLL location changes to C:\Program Files\Microsoft Visual Studio\VB98\VB6DEBUG.DLL, which I assume is just VB6 intercepting calls to the component. When I detach the debugger, it changes back. I should also note that the component is configured to use a specific user identity separate from my logged-in user account, however everyone has been granted access to the component via a user role. The component activation type is also 'Server Application,' however setting it to 'Library Activate' doesn't seem to make a difference.
I've also tried using the VC++6 IDE, and VS2010, but had no luck. I was able to debug the dllhost.exe in VS2010 and was able to hit some breakpoints, but the symbols weren't loaded properly. I tried compiling the DLL with debugging symbols and loading those to the VS2010 environment via the Debug settings menu, however that didn't resolve the issue.
I also didn't find the component services JIT Debugger to be very useful. I'd much prefer to just be able to debug in VB6.
What amazes me most is that this code is thousands of lines and has been maintained without the use of any debugger whatsoever. My young, spoiled self isn't ready to accept that this code can't be debugged.
Is there a way to precompile the ASP.NET MVC views on an Azure Web App (specifically when published via Release Management on VSTS)?
Once each view has been hit once, the page subsequently renders very quickly. But that first delay can be a doozy for users and there's no way to script touching each page.
I'm not sure if I need to change something in the build/release processes on VSTS (I am using the Visual Studio Build build step and the Azure Web App release task) or if I need to run something on the Azure Web App instance after it is released (or something else altogether).
It seems like finding some way to call aspnet_compiler after publish might be what I need (and I have seen that in reference to Web Roles on Cloud Services) but I can't get that to work.
Calling
%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler -v "/" -p "d:\home\site\wwwroot"
via the Console in the Azure Portal executes just fine (and finds errors if there are any) but doesn't have any impact on startup time - hitting a view the first time still takes a long time.
So maybe that isn't the right direction.
I've looked at RazorGenerator (including the .MSBuild nuget package) and I couldn't quite get it to work, but really I was hesitant to make so many changes to the projects just to get precompilation on release.
Also note that I am currently using TFVC, not Git, in VSTS, so the Kudu/Git integration (that does seem to trigger the precompilation according to some articles) isn't available to me as far as I can tell.
Other ideas?
You can add "/p:PrecompileBeforePublish=true" argument in "Visual Studio Build" step:
Then the task will call aspnet_compiler during the build process and generate a precompiled output for deployment.
In visual studio 2013+, choose Build->Profiles. Select the profile, then choose "Settings". Underneath "Configuration", expand "File Publish Options", and then check the "Precompile during publishing" option.
I need to write a program which will send out e-mails...
It needs to be set up as a scheduled task in Windows and be called on demand from an ASP.NET website.
I know how to write an executable (and my ASP.NET website is near completion).
I know how to code the program, but I wish to avoid duplicating my code in two places!
My first idea was to code a .exe, set it up as a scheduled task, and call it from the code in the ASP.NET website e.g. button_clicked but I'm not so sure this is a good idea.
Is there a better way (more secure, but without much more effort)?
It's an ASP.NET Website Project (not an application) it's not part of a solution - should it have been?.
If you have access to the GAC on the server, then just abstract the code out of the EXE and into a library assembly. Add the library DLL to the GAC. Then reference that DLL from both the EXE and the Web project.
If you don't have access to the GAC you can still do it, just deploy the DLL with the EXE and in your web app's bin.
EDIT
here's how to create a library assembly http://broadcast.oreilly.com/2010/07/understanding-c-namespaces-and.html
Have the sending code inside of ASP.NET and have the scheduled task request a password-protected URL on your website (e.g. /send-mails?pw=jdgdifgnfdhg). That way you don't need an EXE. You can execute the http request using curl.exe. Super simple.
I am developing one product and there are 4 separate projects, in that I have developed one EXE project and WCF and I have done switching in debugging mode by attaching WCF project in process of debugging client of EXE and it has worked.
But when I transfer my WCF to servicestack then I could not able switch between them.
I am running my EXE project and and attached my WCF(servicestack) project to process
JsonServiceClient client = new JsonServiceClient("MYServiceURL");
RESTWCF.ServiceModel.Perfmon objBalPerformanceDataProperties = MakeObjectForServiceStackToInsertData();
var res = client.Post<RESTWCF.ServiceModel.Perfmon>("/perfmon", objBalPerformanceDataProperties);
When I click F11 on client.post I could not able to switch in WCF project, I think you can make sense of my problem.
Give me some solution of this problem so I can debug my code of WCF project (to find error :) in that)
Thanks.
You can only debug one host project at a time.
If you want to test the server set the ServiceStack project to be Start-up Host and press F5 to start debugging the ServiceStack host. Put a break-point at the start of the service you want to hit.
You can then just Run (i.e. without debugging) the client application which if everything is configured correctly, it should hit your breakpoint.
To make sure you're debugging the service correctly, instead of running the client first try calling the web service via a url, e.g:
http://localhost/MyServiceUrl/perfmon
If it hits the break-point you set, then all is well and you can run the client application as mentioned above.
Also it's a good idea to include ServiceStack's debbuging symbols, i.e. it's *.pdb files in the same folder as it's *.dll's - as it helps with debugging.
Note: WCF has nothing to do with ServiceStack - In a lot of cases that's considered an insult :-)
I have an asp.net website that I'm looking to migrate over to Azure. I have been doing some analysis of the website and code to understand issues with the migration. I am confident that 95% of the code will be fine as most of it is pretty standard web forms and dot net programming.
However, I have just run across an ActiveX component that is installed into the \windows directory on the webserver.
I am wondering if this will be an issue for the migration? There could easily be a number of follow-on questions as well depending on the answer. How do Azure web roles handle instantiation of activeX server components? Can I include the DSINTX.OCX file into the solution or do I wrap it in a dotnet assembly?
private DSINTXLib.Dsintx m_dsintx;
...
m_dsintx = new DSINTXLib.DsintxClass();
Installation of the ActiveX component should not be difficult. You can use a startup task running elevated to install it, assuming that there's an unattended installation mode for it. I blogged about this process for a Windows Service a while back.
http://blogs.msdn.com/b/golive/archive/2011/02/11/installing-a-windows-service-in-a-worker-role.aspx
If you don't have an installation file, then create a script that installs and registers the control and then use RDP to your role instance to debug. The blog post goes over some of these techniques as well. (Use notepad to create the command file, not VS.) You can add the OCX to your project, but be sure to set the Copy Local property to True so it becomes part of the package that is sent to Azure.