I need to see the code of the last successful build of my asp.net web page (the one which is shown when you run the code, in a case that the code as some bugs in his current form). how is it possible?
You need to use some sort of a git service. Some are available out of the box in the Team Explorer pane.
Related
I am trying to build and compile an ASP.Net solution. The solution is new. Here is how I create it:
For this demonstration I avoid creating anything post-creating the project,
And here are the errors that I am getting:
All errors above, lead to the following place:
Any direction would be greatly appreciated!
Thanks!
Ok, assuming you looking to create a asp.net webforms app?
Your screen caps look ok, and it not clear why your resulting application has errors, or build issues.
I would try to create another project, different name. See if that works.
Better, try tapping windows key, type in 2022, and then right click and try run as administrator, and see if that helps. (the default source folder might for some reason require elevated rights to work).
And if above does not work?
then I would try a repair, or even re-install of VS. Perhaps the templates are messed up.
Following your exact steps, my vs2022 created asp.net web applcation without issues.
best guess:
Your VS install is messed up, re-install, or repair.
tools->get tools and features.
Then: close the modifying window, and you should see this:
Try a repair.
Thanks Albert and everyone attempting to help!
What I did that solved the issue is to click the errors, and I was redirected to the following document:
Here, I deleted every tag that was highlighted in any of the errors, more specifically, things related to Video Builder Cloud Services (VBCS), and off I go :)
Within Visual Studio, I use Web Deploy.
Within the settings, it asks for 4 fields to be filled one (and 1 optional)
I am guessing, behind the scenes, it is calling msdeploy.exe and passing them as command line arguments
I'm struggling to map these across as I want to use
shell: cmd
run: '"C:/Program Files (x86)/IIS/Microsoft Web Deploy V3/msdeploy.exe"
-verb:sync
-allowUntrusted
-source:contentPath="%CD%\myDomain.Ui\bin\Release\netcoreapp3.1\"
-dest:contentPath=domain,computerName="<server>:443/msdeploy.axd?site=<site name>",username="<user name>",password="<password>",authtype="Basic"'
As you can see, source:contentPath uses the actual path and this works fine in GitHub actions. I'm having issues with the dest: part. In the example above, I've used the titles (so instead of myUserName, I've used as it shows in the screenshot)
I have 2 questions.
When I click "publish" within Visual Studio, if it really is just calling msdeploy.exe, then is it possible to show this in the output. If I knew how to do that, I may be able to answer my own question
Have I mapped them correctly
As for how to see more details, this KIND OF works:
Visual studio 2017 Verbose publish
The relevant part is
To change the amount of information included in the build log On the menu bar, choose Tools, Options.
On the Projects and Solutions page, choose the Build and Run page.
In the MSBuild project build output verbosity list, choose one of the following values, and then choose the OK button.
And then, at the very end of the build, search for MsDeploySourceProviderSetting
You can then see the details! This gives some of the values, but not all!! It doesn't really answer the question! However, it got me part way there
It needed to be
-dest:contentPath=<site name>,computerName="<server>:443/msdeploy.axd?site=<site name>",username="<user name>",password="<password>",authtype="Basic"'
EG, my website ULR is https://example.com and in IIS, it is set up as MyWebsite
-dest:contentPath=<MyWebsite>,computerName="https://examplecom:443/msdeploy.axd?site=MyWebsite",username="<user name>",password="<password>",authtype="Basic"'
Also, if you do use VS as I did, it may give you a different port, so be aware that 443 may not be right!!
I have recorded a test case via Katalon Studio -> Web Recorder and now I'm running it to check if everything goes as expected (still in Web Recorder UI).
Something goes wrong, can I see the current step Katalon tries to execute?
I think there is a problem about object's xpath. When you add objects to object repository with recorder , sometimes they are not working because it is coming as a default marked tag and class. You should select xpath and you can use easily.
Ok.. I have looked through this site and just can't seem to find the answer I am looking for.
We have a multi server setup for our web sites, typically (DEV/QA/PRODUCTION). Our sites are .net which require some sort of build before being deployed. We are using SVN for source control and are looking for a tool/website/something that will allow our project managers to push button deploy changes to the different environments. It seems there is no silver bullet for this, am I correct in this assumption?
I like the functionality of Springloops but can't find any information regarding its use with .net. Sparing details, it would be nice to see a diagram of sorts on the whole end to end process. What I mean by that is, if multiple different tools are the only answer (no silver bullet), then a diagram that shows where the tools sit in relation to the whole process.
Look at CruiseControl.Net. It'll let you automate your builds and if there are errors it can notify certain people and even flash a big red light in the office.
The other thing it can do is automatically deploy to a chosen region such as Dev/Test/Stage/Prod when there are no errors.
Though you may want to make Prod a manual press of a button. :)
The new on click publishing features in Visual Studio 2010 are pretty easy to set up ans use: http://vishaljoshi.blogspot.com/2009/05/web-1-click-publish-with-vs-2010.html
Supports configuring IIS and deploying SQL packages too.
There is a msdeploy.exe file included in the that you could setup to run with .bat files or some configurable script runner.
Try ClickOnce deployment. Once a update is deployed on the server the client applications are automatically get updated on every client on their next run.
I have three Silverlight 3 applications in the same solution. In my asp.net hosting project I have a seperate page for all three projects. When I navigate between the pages, the only Silverlight breakpoints that get hit are the ones the initial page I load.
This problem has only started recently. I used to be able to debug between all silverlight projects at the same time. Any ideas? I have deleted the ClientBin folder, I have deleted all files and re-retrieved from source control. Nothing seems to be working.
"The problem has only started recently". What changed? Here are some guesses:-
You upgraded to Windows 7
You installed some more memory
Some other memory guzzling app is no longer running when you are testing.
By default IE8 will run multiple processes at least 2. One for the browser frame and one for the content of the intial tab. As you open more windows and tabs IE may add new processes to the set it is currently using.
When you debug VS will launch an new IE8 session and will attach to the process handling the content of the single tab that is open, (it doesn't bother attaching to the parent frame process). However as you navigate about your application IE8 will start new process that VS won't be attached to. This forces you to open the Attach to Process dialog and do it manually.
You can control this IE8 feature (called BTW LCIE, Loosely Coupled IE) from the Registry.
In the Key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main add a new DWORD value TabProcGrowth. Set its value to 1. Now IE8 will only ever create 2 processes per session one for the frame and one for all the tab and window contents which is the one the VS will attach to.
This perhaps is a bit draconian if you also use IE8 as your general browser. One option is to leave IE8 for test purposes and use another browser for general browsing. Another option is a variation of the above. Instead of creating TabProcGrowth as a DWORD create it as a string type instead and set is value to "small". In this mode IE8 is much less aggressive in the number of processes it will open. Of course you could create a couple of scripts to create and delete the registry entry.
Note without the registry entry IE8 uses its own hueristics that depends on available memory etc to determine if a new process is warrented or not. This might explain why in the past your debugging worked and that for apparently no reason it stopped working.
Here was the issue:
One of my child windows had a Silverlight that calling a .Net Ria Service. The service call ended in an error.
The next time several I debugged, the debugger did not attach to the child windows. I had to attach to the child windows manually.
I fixed the Ria Service call so that it did not end in an error. And had to manually attach to the child windows in that debugging session. However in subsequent debugging sessions, the debugger automatically attached.
I tried breaking the Ria Service call and I had to manually attache again. What is a little weird is that closing Visual Studio and even rebooting the machine does not make Visual Studio automatically attach again. You have to have a debugging session where the child window make a sucessful call to a Ria Service to fix it.
NOTE:
The RIA error that was breaking my debugger was caused by a misspelled include in the domain query (ie...
return Context.SOME_ENTITY.Include("Misspelled_Association_Property");
) not all RIA exceptions cause this problem.
My scenario has a number of specific cases that I will go over. I don't have all the things handy to test a more general scenario, but I will when I finish my project unless someone does this first.
Here is what I have:
I am using the a LinqToEntitiesDomainService from the July 2009 Preview release of .Net RIA Services.
To complicate things a little more, since my application is using an Oracle backend, I am using DevArt's dotConnect Entities provider as the EntityFramework model for my domain service.
When I get time, I will try this on the Nov 2009 RIA and a standard SQL backend and EF to see if I still have the same issue. If this is the case I will report it to Microsoft as a visual studio bug.