We have reinstalled ProGet as we rebuilt our server after a security hole was discovered (unrelated to ProGet). The feed is visible in the browser, but inaccessible in Visual Studio.
While rebuilding our server, we have ProGet running on a temporary Azure server, which is working and serving our NuGet packages. In comparing the two, one notable difference is the API endpoint URL for the feed. For the ProGet on Azure, it is a reasonable looking, fully qualified URL.
On the ProGet we're attempting to set up while building our new server, it actually contains a password and the word "Default" (we have deprecated this password).
This doesn't seem to be right, but I don't think it can be changed. I've tried reinstalling ProGet, but it's retaining my packages and the feed.
How can I fix this so ProGet will serve Visual Studio? Thanks in advance.
What version of ProGet are you using?
If it's v3.7 or later, the "Package Source URL" on the Feed Overview page is what you want to enter into Visual Studio:
The "Default" you're seeing is simply the feed name, and there are no passwords visible in that URL. The host name displayed there is simply the name of the machine it's running on, so you can also use a DNS name or IP address if you're on Azure (i.e. http://{sitename}.cloudapp.net/nuget/{feedname})
This was corrected by clearing the value in the ODataBaseUrl in Advanced Settings. Upon doing this, the API Endpoint URL changed to what it should be- a fully qualified URL rather than a strange string.
Related
I trying to use Visual Studio as I required to learn .NET and visual studio as part of new job. Normally I program everything in Notepad++ (PHP/javascript) because it just works fine for me.
I have been on for three days trying to install Visual Studio, finally got it to install with the components required, as you can imagine my experience so far of Visual Studio is not too great.
Sound cliche but following a nice simple tutorial to get the basics out of the way, as you do.
When I click to debug or the IIS Express button I am greeted with this error.
I have tried restarting the project
I have tried restarting Visual Studio
No matter how many projects I create I get the same error.
I have been trying to fix this for hours now, I have turned on IIS in windows features. I am missing something, do I need to un intall wampp (which isnt actually running)?
The folder I create has no permissions and is accessible however the read only box is always ticked even if I uncheck this and apply settings.
I have tried manually creating a site in IIS manager, and again I get this error on authorization.
The server is configured to use pass-through authentication with a
built-in account to access the specified physical path. However, IIS
Manager cannot verify whether the built-in account has access. Make
sure that the application pool identity has Read access to the
physical path. If this server is joined to a domain, and the
application pool identity is NetworkService or LocalSystem, verify
that \$ has Read access to the physical path.
Then test these settings again.
Any help would be amazing as I'm pulling my hair out here.
This is likely due to file rights. I have run into this when I am trying to run my code that lives on a network share, or more commonly when it is living on the host and I am running Windows in a Virtual Machine. I would confirm that you have sufficient disk space, the code is living on a local drive, that the folder is not read-only and that the running user has rights to write to that folder.
It looks like you are running from a folder on your Desktop folder. This should be fine. If you got that code from a Git server sometimes the files come down as read-only. I would confirm that the "Current Work" folder is not read-only nor are any of its children. I would also go into the Security tab of the folder's properties in Explorer and grant "Everyone" full control (probably safe since this is just a developer environment). Test after each of these.
We have the same error on both our Team Web Access AND our SharePoint project portals from our TFS2010 server.
Access through Visual Studio appears to be fine.
However, anywhere a list of work items should appear in either web environment we are instead seeing
Method not found: 'Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.ScopedFieldDefinitionsClass Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.NodeClass.get_GlobalFieldDefinitions()'.
We are unable to create items in either web portal as well.
We have tried clearing caches on the TFS and clients then restarting TFS to no avail.
Any suggestions greatly appreciated.
This definitely seems like a cache issue unless you updated TFS recently. Web Access and SharePoint web parts have different cache locations.
You can find the correct cache path by looking at web.config appSettings value with key "WorkItemTrackingCacheRoot" or something like that. Please make sure you blow away the correct cache.
I'm trying to publish an Azure application, but can't sign in using Visual Studio 2010. I get the error message "The web browser cannot be started. To resolve this problem, you must restart Windows."
I've tried both rebooting and making Internet Explorer the default browser, but I still get the error message. This also occurs when clicking on other links (for example "Online Privacy Statement" in the same publish dialog box).
How can I fix this, or alternatively, are there any other easy ways to publish to Azure?
There are several ways to publish to Azure. Depending on your preference, some of them may be easy. Some, not so much.
First of all, are you using a source control? If you're using git, then you can use Azure Git Repository that comes free with Azure Websites and also Azure Cloud Services. So when you push your code to the Azure repository, it automatically publishes the final bits to the corresponding site.
If you're using TFS locally (at home or office), you can set up a build task that'll deploy the bits to Azure. Also, check out TFS Preview if you are comfortable with a Microsoft hosted free TFS server.
If you feel comfortable using FTP, you can get the FTP account details from the Azure portal when you set up a new azure website or a cloud service.
Finally, one of the easiest way to publish to Azure is to use the Publish Profile feature.
You'll find a link called "Download Publish Profile" associated with
your azure website. Click on that to download the profile (an XML
file).
Then right click on your VS project and hit Publish. Under Profile
tab, select "Import" and pick this downloaded file.
It should populate all the details for you. Test your connection to make sure everything works okay.
Publish and ENJOY!
UPDATE: Based on the comment to this answer, adding screenshot to show where to get the FTP details for your azure website.
I have a problem which I thought could be common, searched the web for it but found nothing.
We're using a shared development machine, and every developer connects through RDP and has his own profile, desktop, etc.
The problem I am encountering is with IIS express. Since it is configured at user level (applicationhost.config inside documents/iisexpress/config) and the port configured must match the one declared in the .csproj file, two developers can't possibily run on the same port, as it gives the error "the port is already in use".
So to make it work we have to manually change the port both on the csproj and in the applicationhost.config for every developer, but it's only a temporary fix as when we commit our changes to SVN, the csproj file gets merged, so we have to do this process every time someone commits/updates.
My question is: is there a clean way to use IIS express with Visual Studio 2010 on a shared development machine?
Thanks.
Partially tested answer. Not sure how it'll work on a multi-user workstation. It might give you, or someone else here, a jumpstart to a proper solution that works best in your existing environment.
It appears that Visual Studio stores all the web configuration in the csproj/vbproj and IISExpress stores its configuration in %userprofile%\Documents\IISExpress\config\ApplicationHost.Config.
Normally, we store the csproj files in source control, but ignore the csproj.user file so that each person may have some unique settings, such as the web configuration.
Each user who signs into the box must have their own profile.
Each profile must have their own copy of the source code.
Each user's copy of the source will contain their own csproj.user file.
Ignore .**proj.user* files in your source control.
Copy the web settings into the csproj.user by unchecking the option Apply server settings to all users and then commit to source control.
Each user who pulls a copy of the source will have to configure their web settings, use a unique port that the others users are not using, and uncheck the box above so that their configuration is not passed on to the other users.
Doing this, Each profile will have their own IIS Express ApplicationHost.Config configured with a port that is different from the other profiles. Each user's copy of the source will have a csproj.user that is configured with the same port in their profile's IIS Express configuration.
For reference:
I've tried changing IIS Express's ApplicationHost.Config to use a different port than what Visual Studio expects and Visual Studio is unable to connect the debugger to IIS Express.
How IIS Express's configuration works: http://msdn.microsoft.com/en-us/library/ms178109.aspx
The best option you can use is to take advantage of the Import functionality built into MSBuild.
Essentially, you would create a seperate build target for each user. You can then import this target from this referenced file directly. I would then recommend creating this file on the server (for each user), but leaving it outside of source control.
This should allow each user to have a custom IIS port without conflicting with others.
I think you can create subdomains for each user and implement the required changes and do the testing. In this way each user can his own subdomain and port and hence work independently on the shared IIS Express.
You probably won't like my answer but here's my thoughts:
As you noticed, the configurations are tied to the user profile and not the server; this is because IIS Express is not intended to be used as a shared development server. You should be using full IIS.
I do not see any benefit or reason to use the same physical box for development. Admittedly, I don't know all the details of your scenario with licensing or workstation resources, but it doesn't seem like you gain much from having everyone RDP into the box to use Visual Studio - each person still needs a license, performance will be slower, and you shouldn't be working on the same project instance.
You should seriously consider your entire setup for development:
Each developer should use Visual Studio on their workstation, and debug/test there using IIS Express (configured with the same ports and settings across all machines - very easy).
From there, your developers should check their code into source control, and examine conflicts that may or may not arise. I'm not sure about SVN but the MSBuild automation available in TFS can be use to setup a continuous build policy that deploys to a common IIS installation so that your merged code is tested and usable from the full IIS installation mentioned above.
Anything else would be a workaround/hack that will bite you in the butt later.
I'm making a Sharepoint visual web part in Visual Studio 2010 and it seems like out of nowhere I started receiving the error: "Error occurred in deployment step 'Recycle IIS Application Pool': Not found"
In the output for my program it says which application pool it's looking for and I know it exists because it shows up in IIS Manager
Now I've already tried resetting IIS, along with recycling the application pool manually in IIS Manager.
Really I'm sort of at the end of my rope and any help would be greatly appreciated.
This usually happens when the user that has run Visual Studio doesn't have rights to Recycle the IIS application pool.
To solve this, run visual studio with some user who has rights (shift + right button -> run as different user) or try to follow this:
http://msdn.microsoft.com/en-us/library/aa954062%28v=bts.70%29.aspx
The simple solution for the above issue is
Step1:Close the Visual Studio
Step2:ResetIIS
Step3:Open Run and Enter Services.msc, Restart the "Windows Management Instrumentation" service
Step4: Recycle the Application pool in inetmgr.
Step5:Reopen the VisualStudio now deploy.
Hope it will help others.
Thanks & Regards
Kishore Appini
When I experienced the same error, checking the following helped me:
Make sure the Web Application exists on SharePoint.
Make sure the site collection you are trying to deploy to, exists.
This is the siteURL specified in your project's properties. To see
this property, you have to press the F4 key after selecting the
project in solution explorer (in Visual Studio).
In my case, I had not created the site collection and also the siteURL had a previous server mentioned in it.
You need to set the 'Site URL' correctly in the project properties.
click on your project name in the solution explorer and press F4 for properties.
Then check the Site URL.
The Site URL must be the same as Project Server URL.
example http:// spsw001/pwa
This solved the problem when I got this error message.
This must be the solution for the scenarios:
http://praveenbattula.blogspot.in/2013/07/error-occurred-in-deployment-step.html
If you have a public URL for your collection which is a DNS entry that is pointing to your SharePoint server then what you need is an "Alternate Access Mapping".
Go to Central Admin > Application Management > Configure Alternate Access Mappings and create an internal URL for your public URL.
Set your project server url property to point to the newly created alternate access mapping and it should work.
Note: This is valid for SP 2013
In my case it was due to missing database permissions. As mine was a DEV box, I just added my Windows account (=the account I was logged into the DEV server) to SQL Server as sysadmin.