I'll preface this with the fact that I'm very new to Visual Studio, so I am prepared to hear that my problem lies in something I haven't read yet.
I have a database first project in Visual Studio 2015 v.3 that I am attempting to publish to an existing Azure account and resource group.
I have successfully converted it to an Azure project via the menu options: Build > Publish to Microsoft Azure.
I can successfully build both the local and the Azure projects without error, but whenever I attempt to edit the Roles in the Azure project to add the Azure connection string as per the tutorial found here, the program hangs up irretrievably. This makes my twelfth attempt to edit the Roles.
It took Visual Studio five tries to publish to Microsoft Azure using the menu options above.
To fix this, I have tried all of the following:
Restarting my computer
Restarting my Azure connection
Restarting Visual Studio
Confirming Visual Studio's connection to the Azure account I want to publish to
Checking to be sure my Azure SDK (version 2.9.1) and Visual Studio (version 3) installations are the most recent versions and that the installation appears to be clean
Removing the Azure portion of the project, cleaning and rebuilding the local solution, and reattempting to publish to Azure
Cleaning and building both solutions before attempting to edit the Roles for the Azure portion of the solution
Confirming that the resource group I am attempting to publish to does exist at the specified connection string and contains the necessary resources (in this case, a server and an SQL database)
I am attempting to connect (for now) with HTTP and not HTTPS, as per other similar questions about Visual Studio 2015 freezing while publishing to Azure
Confirming that I am able to connect remotely to Azure via Visual Studio (this is probably a gimmie, but it doesn't hurt to be specific)
I also notice that when I attempt to browse the Azure features on the menu to the left of the Visual Studio window, Visual Studio freezes (particularly if I click on the links for Data Factory, Mobile Services, Service Bus, and Virtual Machine).
Server Explorer is showing that I am logged in to Azure with the account I'm attempting to publish to.
I can reach, read, and edit the local database files. I can also run the local project without error.
The application was configured to use an IIS Web Server and uses SQL Express. It froze repeatedly while attempting to change configurations from the IIS Express and LocalDB default to IIS Web and SQL Express.
I do have the application backed up locally as well as via a private GitHub repo just in case I manage to bork it permanently trying to do this.
I would very much appreciate the help.
edited to add: I'm currently running Windows 10.
edited again to add: The task manager shows the load to memory and CPU during the period when Visual Studio is frozen to be less than 15%, the majority of which is not Visual Studio. It shouldn't be a hardware issue, but I did try closing the majority of the background services that were non-essential just in case there was some sort of conflict occurring.
Making this an answer instead of a comment because while it may be a silly oversight, there's bound to be someone who would benefit from the answer.
The problem was that I was working from a local copy of a remote database. When it came time to push up to the remote, I deleted the local copy and data interface model, and reconstituted the model on the remote database, creating several connection strings in Web.config.
When I attempted from there to publish, Visual Studio read the connection strings in the Web.config for the project and attempted to hunt down the local and over-write the remote database.
Removing all other connection strings from the Web.config for the project removed many of the problems with freezing and hanging that I was experiencing (and made the project run faster by resolving the search for associated project resources.)
Lesson learned: make sure you clean your Web.config file before attempting to push to remote.
Related
I published my site on a web server and it works very well (at least to access it) but I would like to use the DB that was automatically created when I was in a development environment.
I initially checked 'Individual account' by creating the project, made some changes (creation of roles, fields in the ASPnetUser table, etc), did some stuff and then publish it and now I would like to recover the DB i had when i was working with Visual Studio on this app (the data inside does not matter to me).
When I published my site with Visual Studio 2017, I was asked to check the providerName and the context.
So I ticked both options leaving the basic information (System.data.SqlClient & connection string to my context (who's not the basic ApplicationDbContext)).
Then, browsing my site, I tried to connect to a login that existed in development on my machine but no way, I also tried to create a new account (thinking that this would regenerate a db) but no way either.
I looked on the internet but I found nothing, except for Microsoft but they use Azure, which does not interest me.
Could you guide me on the processes to follow (even just a link to a tutorial would be very useful)?
I still specify that the server is on Windows Server 16
The best solution for this, in my opinion, is to install a standalone MS SQL server on your machine and create the base of your project not on localdb, but on that server (you need just to change connection string in your Web.config to do it).
I have completed my .net project using visual studio 2012. How can I export my project so that I can run it on other pc too. The problem is that the database is not working on others pc bt perfectly working on my lappy. Why is it so and how can I solve this problem?? Please anybody help me out....
Get this situation at work fairly regularly as we have multiple instances of SQL Server and MySQL (Not so many of these) and deploying then testing the program can be quite laborious and any change in the deployment means you have to go back to the original, change and re-deploy.
What I would do is install visual studio express, or visual studio 2012 shell on the local machine where the deployment is going to take place and debug there. If it is a corporate environment where licensing is an issue, installing visual studio express will mean that you do NOT have to purchase a license and therefore not incur cost.
The other situation is that you connect from your local machine to the MySql database but you'll have to open firewall ports which could get messy and, testing the program will not give you accurate performance results as your accessing a database over a network thats not configured for it.
There are other options such as using an attached database but again, gets messy with you changing the structure of your program.
My advice is go with the visual studio express solution...
I deployed a web role in windows Azure, based on the following tutorial.
http://weblogs.asp.net/scottgu/archive/2013/10/22/windows-azure-announcing-release-of-windows-azure-sdk-2-2-with-lots-of-goodies.aspx
but when I try attaching the debugger I get the following message:
"there was a failure to launch the remote debugger"
apparently this is a known issue, and the suggested solution from Microsoft is to restart the visual studio and try again, which unfortunately didn't work for me
http://msdn.microsoft.com/en-us/library/windowsazure/dn459835.aspx
Remote debugging may fail to attach to an existing Cloud Service:
After deploying a new Cloud Service the debugger may fail to attach to
an existing cloud service with the error message “There was a failure
to launch the remote debugger”. To correct this problem, restart
Visual Studio and reattach the debugger to the new deployment.
So I thought to ask here in case anybody faced the same issue and found another solution other than restarting the visual studio!
I'm using visual studio 2012, with Azure SDK 2.2
Make sure that you deployed a Debug build to your web role and that you have checked "Enable Remote Debugging for all roles" on the advanced tab during deployment. Failure to do either of these could lead to the problem your seeing.
I was using Azure SDK 2.2, so as to use "Attach debugger", but unfortunately I needed to use SDK 2.1 as 2.2 needs some references that weren't included in 2.1, so I guess this is the problem.
Thank you all for your help
I tried all of the solutions above and found that none worked for me. My problem turned out to be stale or inaccessible certificates that the VS debugger uses to connect to the service. I discovered this was the problem by going to event viewer and found:
A fatal error occurred when attempting to access the SSL client
credential private key. The error code returned from the cryptographic
module is 0x8009030D. The internal error state is 10003.
I had had other problems with permissions on private keys and so I ended up deleting all of the certificates from my personal store (current user) with the "Issued To" equal to "Windows Azure Tools". When I redeployed my service VS created new certificates and uploaded them.
Voilà -- attach remote debugger works again.
I got the same exception trying to remotely debug a VM in Azure, following the guide in Debugging Azure Virtual Machines.
What worked for me was to simply install the remote debugging tools matching my version of Visual Studio (VS2013 Update2).
Further I had to add a new endpoint in the Azure portal. This didn't work initially but eventually using the same public and private port number did the trick. The default port of 4018 worked.
Start the remote debugger program on the client machine in adminstrator mode and remember to set to port number, e.g. to 4018. I chose Windows authentication as well.
From within Visual Studio: Debug menu -> Attach to Process -> [yourVMName].cloudapp.net:4018 or whatever port number you chose. You should now see a list of processes on the virtual machine.
In case its helpful for someone else, I've just spent 3 hours on this! In the end I gave up and using 'Cloud Explorer' (in VS 2013, after installing the Azure SDK) I selected 'Disable Debugging' and noticed it cleared out port rules in the Network Security Group for the VM.
I hadn't seen it set these up (which is where I'd spent hours guessing that these were the issue and trying to figure them out from patchy MS documentation, broken links, etc).
So, I 'enabled debugging' for the VM and saw it set up security rules - something it didn't do the first time!
At a guess this is because I had initially enabled debugging for my VM soon after I installed the Azure SDK into VS. Since then I rebooted the VS server, and that may have enabled something in the SDK.
Anyway - before spending hours figuring out ports, reboot the VS server and then disable/reenable debugging in Cloud Explorer - you should see a status message (in the Azure Activity Log) saying 'Configuring networking security group debugging port' - this is the magic step that it didn't do the first time around.
I think you should try lunching VS in administrator mode, and see if you always have the same problem.
Else I think you should put more details about your problem.
This is what I did to enable debugging on an Azure VM.
At the time of this writing my current setup is as follows
Windows Server 2012 R2 IIS 8.5 (Virtual Machine)
Visual Studio 2013 Update 4
Microsoft Azure SDK Tools 2.5
Update Visual Studio to the latest Azure SDK
go th the server window (server explorer)
Expand the Azure node
Expand the virtual machines node
Right click on the VM you want to debug
Choose "Enable Debugging" Visual Studio will begin to add a debugger extension to your virtual machine
Once complete, Right click on the virtual machine from the virtual explorer and choose attach debugger
I have an MVC4 web application that uses jquery and some other libs (jquery-ui in particular).
Yesterday I decided to update all the packages via NuGet package manager; my web application worked correctly on my local machine, but when I deployed it to my azure website a javascript error popped out in my browser (it was related to jquery-ui library, something like "$browser is not a function").
I searched the web and found out that the cause of this error was that I was still using an old version of jquery. It seems that deploy process didn't publish the new version of the js libraries even if they have been updated in local project.
I solved the problem connecting via RDP to the Azure machine, deleting the contents of "Scripts" folder and deploying again, but I'm wondering if there's a way to "force" script/libraries update when deploying to Azure.
Edit 1: I'm developing with Visual Studio 2012, using Mercurial as source control provider
Edit 2: I'm deploying to Azure Web Sites
Please, in your future questions clearly indicate what type of Azure Service do you use. An MVC4 web application can be deployed to 3 different type of services: Azure Web Sites, Azure Cloud Service, Azure Virtual Machine!
Since you are talking about RDP, the viable options are Cloud Service or Virtual Machine. But then you say
I solved the problem connecting via RDP to the Azure machine, deleting
the contents of "Scripts" folder and deploying again, but I'm
wondering if there's a way to "force" script/libraries update when
deploying to Azure.
Now the question is how you do deploy to Windows Azure? Is it via Visual Studio's Publish feature to Azure Cloud Service. Is it Visual Studio's Package feature and then using any other method of deployment (upload the package from the portal, use Azure PowerShell cmdlets, or use third party tool to deploy the package)? Is it integration with Mercurial and deployment is done automatically when you check-in?
Any any case, the issue you face is a mixture of NuGET failing to do real clean update of everything. Browser caching - especially for local development - IE caches all the scripts, CSS and images and it is hard to say (without explicitly deleting all locally cached files) which script are you actually using. Simple version control issue - keeping old and new scripts.
When you do a JS/CSS updates I strongly advise all the customers to first delete all browser's cache (crtl+shift+del - works for all browsers) before testing locally.
I highly doubt that if you use a Cloud Service, RDP-ing and deleting anything in the sitesroot folder will help you when you redeploy. What you do in the ROLEROOT drive (usually E:, sometimes F: drive) is dropped of/forgotten when you re-deploy regardless of the re-deploy method you use: in-place-upgrade or full re-deploy. So what you did is actually creating new package and re-deploying your new package.
The fact that you deleted some folder has no effect on your re-deploy action.
I'm trying to deploy a WinForm app through clickonce using a ftp site on my dreamhost account. However, when I try to publish, I get the following error:
Failed to connect to 'ftp://ftp.mydomain.com/client' with the following error: Unable to create the Web site 'ftp://ftp.mydomain.com/client'. The components for communicating with FrontPage Server Extensions are not installed.
Here is my settings on the publish tab
Publishing Folder Location: ftp://ftp.mydomain.com/client
Installation Folder URL: http://ftp.mydomain.com/client
It seems that Visual Studio is not realizing I am publishing to a ftp site and not a site with FrontPage.
Does anyone know how to fix this problem?
Visual Studio only supports publishing to web servers that have Frontpage Extensions installed, regardless of whether connecting via FTP or HTTP. If your host doesn't support them, you will have to publish to a local folder and then upload its contents using an FTP client.
UPDATE: The FrontPage extension components need to be installed on the machine you are DEVELOPING on (Used to publish). The server shouldn't matter--it's simply FTP. On your development system, go to control panel > add/remove programs > and repair "Microsoft Visual Studio Web Authoring Component". Depending on the version you have, you may need to repair VS2010, etc. This will reinstall the FP components on YOUR machine, allowing you to publish via FTP.
Do you recently installed Xamarin extensions xamarin.visualstudioInstall.msi ?
This is cause of stopped deployment component.
Check this discusion:
http://forums.xamarin.com/discussion/30406/bug-after-installing-xamarin
Removing 'Xamarin' from the uninstall/change a program fixed the issue for me.
After that VS 2013 and VS 2015 RC1 deployments started to work again.
what is worth of acknowledgment is the fact that Visual Studio 2010 may report such error due to problems with lacking RAM or after several sleep or hibernation phases with VS turned on. I experienced this with a perfectly well configured server which I have used for ages and done hundreds of publishes, the error came all of a sudden and the only medicine was a VS restart (or sometimes the whole machine's restart). Best regards.
According to MSDN specs, you'll have to add some custom content/mime types to your server for ClickOnce:
If you are deploying a ClickOnce application from a Web server
other than IIS, you may experience a problem if the server is
returning the incorrect content type for key ClickOnce files, such as
the deployment manifest and application manifest. To resolve this
problem, see your Web server's Help documentation about how to add new
content types to the server, and make sure that all the file name
extension mappings listed in the following table are in place.
File name extension Content type
=================== ===========================
.application application/x-ms-application
.manifest application/x-ms-manifest
.deploy application/octet-stream
.msu application/octet-stream
.msp application/octet-stream
DreamHost allows you to add custom mime types in a .htaccess file.