After adding a web role to my Azure project I get a build error within my Visual Studio Team Services environment. Though, I cannot figure out what is causing this. Where is AssemblyAttributes.cs comming from? I cannot find this file in my solution folder.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Windows Azure Tools\2.7\Microsoft.WindowsAzure.targets (2787, 5)
Unable to copy file "C:\Users\buildguest\AppData\Local\Temp\.NETFramework,Version=v4.5.2.AssemblyAttributes.cs" to "C:\a\6e05cef4\xxxx\xxxx.Backend.Api.Azure\obj\Debug\Tijdmunt.Ui.WebRole\C:\Users\buildguest\AppData\Local\Temp\.NETFramework,Version=v4.5.2.AssemblyAttributes.cs". The given path's format is not supported.
AssemblyAttributes.cs is a temporary generated file created by MSBuild, so It's not going to be on your solution. Instead it is going to be under the temporary folder.
Since It's a temporary file and created on every build, I just went to below location and deleted the file, then my solution started to be successfully building again.
C:\Users\UserName\AppData\Local\Temp.NETFramework,Version=v4.5.AssemblyAttributes.cs
Hope this helps someone else.
Related
I have absolutely no idea, what does it means? I only press OK in assembly information in order to specify Assembly Version.
What paths is absent? And what operation VS2022 can not finished? It looks as Visual Studio programmers what is useful error messages are.
I just ran into this problem and for me it was a VB project, and when you modify the AssemblyInfo, it tries to write the AssemblyInfo.vb file to the .\My Projects\AssemblyInfo.vb. Normally when you create a fresh project, I think this folder is created automatically so VS assumes it's there and gives you this error if the folder is missing.
In my case the folder was not checked in to git, so when I checked out the project the folder was not there. I would assume the same is true for c# projects, except the folder expected would be .\Properties\AssemblyInfo.cs.
All I had to do was create the "My Projects" folder at the root of my project and the error went away. It appears you are using c#, so try creating a "Properties" folder at the root of your project and see if the error goes away.
I still don't understand what path Vs2022 can not found and what operation VS2022 can not complete, but manually add CS-file with needed attributes solve this issue.
I'm deploying nodejs application to Azure App Service with visual studio code extension (Deploy to web app). However when I inspect the files section, I found some old file/ files from previous deployment are still exist at /home/site/wwwroot/ folder.
For example first deployment have A.js, and second deployment I renamed it to B.js, /home/site/wwwroot/ will endup with A.js and B.js.
How can I resolved this issue? Any suggestion will be appreciated, thank you!
on publish page click on show all settings.
Make sure Remove additional files at destination.
Before check Remove additional files at destination. showing old file on wwwroot folder.
After check Remove additional files at destination. showing old file on wwwroot folder.
Using Visual Studio 2012, Azure SDK 2.1, I am trying to figure out the best way to create the csx folder for running in the azure emulator. My understanding is that the csx folder is not created until I package the Azure project. I can create a package manually from Visual Studio, but this is not an option for an automated build. The other option is to create the package using the msbuild command line. This seems a bit heavy handed as it will actually do a build which is more time consuming than just repackaging.
So, I thought that cspack might be a more lightweight option. However, when I call cspack with the following command line:
cspack.exe ServiceDefinition.csdef /copyOnly
I get the error: Need to specify the physical directory for the virtual path 'Web/' of role MyProjWeb.
But, I don't do anything like that when using msbuild. I have read a bunch of things about specifying the physical directory and some of the confusion that it can cause. So, I would prefer not to use it unless absolutely necessary, especially since I don't need to specify this when building from msbuild.
So, my main question is what is msbuild doing that cspack is not doing and how do I do the same with cspack?
My other question is, what is the easiest way to generate the csx folder for testing in the azure emulator?
Edit - Resolution
I thought that I would put down how I resolved this here in case it helps someone else. The big answer to my question (thanks to Chandermani and some other reading) is that CSPack with /copyOnly is basically a fancy xcopy to a folder structure according to some rules. If not using /copyOnly it then also does a fancy zip to create a package. Not complaining, it is fine that it is simple, but it is good to know this at the outset. You can use it for packaging anything for azure it is not tied to what can be built in Visual Studio, e.g. a PHP site. Using msbuild has the added benefit of only copying that files that are part of your web site deployment.
So, what I found when I got CSPack working and pointed at the mvc project folder is that it copied everything including source files. Which is not what I wanted. The solution that I could find is to first package the web site then point CSPack at the packaged files. If you do down this path then this link is very valuable as it describes it step by step.
So, it was either having an msbuild post-step in the Web project to package the files and then a post-step in my Azure project to cspack it or to have an msbuild post-step in my azure project to create the package (do cspack with the benefit of only including my web deployment files). Well, it seemed simpler and less error prone to just to have the one post step and let msbuild do the heavy lifting. So, the post step in my azure project is something like:
"C:\Program Files\Microsoft SDKs\Windows Azure\Emulator\csrun.exe" /devfabric:shutdown > NUL
"C:\Program Files\Microsoft SDKs\Windows Azure\Emulator\csrun.exe" /devstore:shutdown > NUL
if $(ConfigurationName) == Debug set CONSTANTSPARAMETER=DEBUG
if $(ConfigurationName) == Release set CONSTANTSPARAMETER=
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe $(ProjectDir)$(ProjectFileName) /t:clean;publish /p:Configuration=$(ConfigurationName) /p:TargetProfile=cloud /p:OutputPath=bin\Cloud$(ConfigurationName) /p:VisualStudioVersion=11.0 /p:overwritereadonlyfiles=true /p:DefineConstants="%CONSTANTSPARAMETER%" /verbosity:minimal /p:PostBuildEvent=
The first two lines shut down the compute and storage emulator.
The next two lines set the preprocessor constants. I found that #if DEBUG was no longer taking effect when built using the msbuild line. I think that this is safety protection that DEBUG is stripped when creating a package. I only ever use the package that is created by an automated build system, so it is safe for me to keep the DEBUG constant.
The actual msbuild line has a number of switches. I'll describe the unusual ones:
/p:PostBuildEvent=
If we don't set the postBuildEvent to empty then the same post step will keep getting called forever. And ever...
/p:VisualStudioVersion=11.0
Those clever guys at Microsoft made it possible to open projects with both Visual Studio 2010 and 2012. Which is great, but can bring great sadness when you run msbuild from the command line and end up with nasty MSB4019 error messages because it is looking in the wrong Visual Studio folder for the Azure tools.
Also, note that that I use the cloud profile. Since I am only after the csx files it doesn't seem to make a difference whether I use local or cloud at this point. When I run in azure I specify ServiceConfiguration.Local.cscfg.
Edit: In the end I took this out of the post step and put in my automated build. My original intention was that running the tests from my dev machine would be the same as my automated build, but the post step took too long and the views were sourced from the obj folder rather than the proj folder when running under the debugger which meant I had to copy across when making changes on the fly.
Unanswered questions
It would still be good to understand how msbuild does things to reduce knowledge friction when dabbling in this area. Does it create a package for the website and pass it to CSPack? Or does it parse the project files and then pass some crazy arguments to CSPack? Also when you run an azure project in the debugger, it runs in the emulator with only the binaries in the csx folder (not the images, etc). How does it do that? It would be great to see some description with pictures of the Azure build pipeline with that showed the lifecycle all the way to deployment. That might also explain why there are two copies of the binaries. Also, this would have been a whole lot easier if Visual studio had a project flag like packageOnBuild for the Azure project with options to do a copyOnly or to create a package. I see no point in uneaten cake. Edit: There is a DeployOnBuild setting that can be added to csproj.
Finally, as I mentioned the whole purpose of this is to get a csx folder that I can point the emulator at so that I can run my unit tests on my dev machine. I do the formal packaging on a build machine so don't really need it in Visual Studio. So, really I don't want to package anything and was hoping that there was an easier way of achieving all this.
Since msbuild uses the the azure project file to perform the build, it can derive a lot of information form the project file.
For cspack, the assumption is the role code has been compiled and is available for packaging. Since cspack does not depend upon project file, it needs a explicit information for the code path of the the web\workerrole project. The csdef file does not contain any such information. I suggest if you want to use cspack. Look at its documentation and try to create a package for emulator deployment from command line (CopyOnly option). Once you find the correct syntax you can embed it in you build script.
I am trying to publish an application with VS2012 and when i try and make the package i get an error that access to the path is denied. I have checked and my user has full control and verified the path.
VS is trying to access .pubmxl file that is there.
I have also tried running VS2012 as administrator.
I had this same issue (VS2012: Access to path is denied when executing publish) and found a way to allow Visual Studio access to the file.
If you open the pubxml file in Visual Studio, make an edit, and save the file, Visual Studio is able to successfully publish using that file. Hope this works for you too.
Creating a new profile worked for me. I got this error when I tried to change the path of an existing profile, and Unfortunately I could not find the original pubxml file, otherwise I would have simply copied it to the new location and followed advice #1 (edit the file in location from VS2012). It's easy enough to create a new profile as there aren't many settings anyway.
I have experienced this issue and I noticed that the files were "Read-Only". Selecting the files and removing the "Read-Only" attribute allowed me to Publish successfully.
Sounds like TFS feature rocks again. Remove publish profile from local repo and get latest version afterwards, then you should be fine.
I had the same problem and fixed it by removing my Publish profile and creating a new one.
I'm attempting to use Web Deploy to Publish a Web Application.
I want Visual Studio to delete any files that no longer exist, so I've checked the "Remove additional files at destination" setting in my Publishing profile.
However, I want VS to ignore the /Content/uploads folder, as it contains contents that my users have uploaded. Naturally, the contents are different in my development site than they are in the live site.
Unfortunately, I have been unable to discover a way to make Visual Studio ignore this folder when publishing (it wants to delete all of the content, since it doesn't exist in the project).
Does anyone know of a way to exclude specific folders on the target site from being examined by Web Deploy?
I had a similar problem, wanting to keep some files in the deployment package even though they're not part of the project.
Try to create a custom MSBuild target for this, that works for me.
Here is a Getting Started MSBuild reference
Hope this helps.
All the best.
I was unable to find a suitable solution for this issue, so I've created my own:
https://pubsync.codeplex.com/
PubSync enables quick and reliable file syncing for publishing Visual Studio projects.