In our solution we are interacting with SAP using the "Classic" API of the SAP RFC SDK.
We have hosted the application in Azure Services, hence not possible to place the librfc32.dll in the required path of C drive.
We have added the librfc32.dll in the solution and marked it Copy Always to the folder.
While we publish the solution locally and deploy using FTP in Azure Services, it works fine.
However when deployed using ADO pipeline, it gives the below error.
We have checked both published and ADO generated artifact and in both places the librfc32.dll is present fine.
Cannot call classic RFC API. See help for details. Please put a recent 64-bit version of librfc32.dll in your System32 folder (typically C:\Windows\System32). See SAP note 413708. Please make sure you have installed Visual C++ 2005 SP1 ATL Security Update (x64). An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Any suggestion?
Related
We have an application that utilises a third-party COM object (provided by a very well known finance/accounting software company).
In order to build this using VS on a dev machine yo must run tlbimport.
Is it possible to building this using DevOps builds on a MS hosted server, or do we need a self-hosted build server with the tlb file imported??
The tlb import tool is automatically installed with Visual Studio. You can refer to this official document.
Microsoft-hosted agent includes Hosted VS2017, HostedVS2019, etc. So I think you can build
this using DevOps builds on a MS hosted server.
I have a web app, and I've setup VSTS to create a package in build, and then deploy it using release management.
It puts all of the result in the wwwroot of the site if I look at it in ftp so I get:
/site/wwwroot/
/wwroot
/
This doesn't run and I get a 404 error.
If I use the URL and go say /wwwroot/images/ it returns it just fine.
The app is set to use .net core and I'm doing a self-contained package.
How do I get VSTS release to put the files in the right place and what is the right place ? I can't find any documentation on this anywhere. Everything is to do with Windows.
Also, what linux target should the dotnet application be set to for self-contained? I have it using ubuntu but I'm sure that's wrong and it's something else.
Please use Azure App Service Deploy task with 4.* (preview) version instead, and deploy again:
I had a similar issue and I responded here. Essentially you need to have a startup command pointing to your DLL because Dev Ops deploys the package in a different way than VS.
Deploying .Net Core to Linux WebApps on Azure with DevOps
Is there a way to deploy .rdl files in structured folders that are not already on a report server? The goal is to deploy the structure from windows explorer to the target report server, which has the same structure.
I recently read this article and code, which deploys from server to server.
https://azuresql.codeplex.com/releases/view/115207
We are trying to create a build environment where the deployment of rdl files comes directly from our source control, and would like to use a script that has been as widely used as the one in the link provided.
Thanks for your time,
In the SQL Server install folder there is an executable called rs.exe. You can use this, passing it an .RSS file that contains the configuration that you want to deploy. You can then bulk deploy from your folder to Reporting Services.
RS.exe
If you have the source .rdl files in TFS you can use Team Build to process and create the .RSS and likely a zip package. You can then have it deployed by Release Management for Visual Studio 2013 through a specified release pipeline that pushed it from Dev->QA->Prod.
You can get information on how from Professional Application Lifecycle Management with Visual Studio 2013.
I deployed a ASP.NET MVC4 app with SQL Server CE database, but I'm getting
Sorry, an error occurred while processing your request
I am using VS2012 to publish this app to azure website. How can I solve this issue? Thanks.
To summarize and so an answer can get marked on this to help the next person that comes by.
When running into issues on azure-web-sites FTP is a handy debugging tool which enables you to:
Verify that the dll exists in your bin directory
Sometimes the .gitignore file blocks directories from being checked in
Verify that your web.config file has the proper version of the assembly configured
NuGet can help, but it's ultimately up to you to verify your dependencies
Here is a good article to follow on the subject: http://www.dotnetcurry.com/showarticle.aspx?ID=883
Unfortunately with VS 2013 Compact edition is not supported any more, so things are somewhat tricky.
Just went from TFS 2008 to 2010 at a client site and now wondering what happened to the TFSBuild.proj files from the TeamBuildTypes folder. I've already got the builds and drops working and now I need to get the old deployments working again. We used to do this with AfterBuild targets in the TFSBuild.proj. That mechanism seems to have moved or disappeared in 2010.
Can anyone point me to an article or describe how the deployment options have changed in 2010?
Specifically, I need to support running psexec to install and enable Windows Services on remote deployment targets and I need to deploy some web sites / web services to remote IIS nodes as part of the automated builds.
EDIT: Just found this: http://blogs.msdn.com/jimlamb/archive/2009/11/03/upgrading-tfs-2008-build-definitions-to-tfs-2010.aspx I'm more than a little taken back by the breaking changes between 2008 and 2010. I'm gonna need advice on how to deploy remote sites and services in the new default build process template mechanism.
Check out Vishal Joshi's PDC talk on Deploying Web Applications with VS 2010 and MSDeploy. On his blog, you'll also find tips on building MSDeploy packages with MSBuild. You can run psexec from your MSBuild script or, potentially, from a customized build process template. With TFS 2010, you can use MSBuild and Windows Workflow to solve your build automation problems.
Alternatively, you can use the "Upgrade" build process template and continue using your TFSBuild.proj file. This is the default behavior for upgraded build definitions for backwards compatibility. In that case, your build is still primarily driven by MSBuild with just a thin workflow to allocate an agent and run MSBuild.
Another option is to use TFS 2010 Build Agent on the server that you deploy to. This is how Visual Studio Lab Management deploys.
I have written a blog post about this: Continuous deployment with TFS 2010 Build Agent