I try to setup source server without SVC- I want to use a simple UNC path as a source storage.
I made small console project with a single file and try to make it source indexed.
I have following stream file:
SRCSRV: ini ------------------------------------------------
VERSION=1
INDEXVERSION=2
VERCTRL=Test
DATETIME=Mon, 04 October 2010
SRCSRV: variables ------------------------------------------
SRCSRVTRG=
SRCSRVCMD=cmd /c "copy" %var2 %targ%
SRCSRV: source files ---------------------------------------
C:\Users\mb\Documents\Visual Studio 2010\Projects\TestSymbolServer\Program.cs*\\mbvirt-pc\symserver\source\Program.cs
SRCSRV: end ------------------------------------------------
When I try to write to my pdb with use of pdbstr like this:
pdbstr -w -p:"C:\Users\mb\Documents\Visual Studio 2010\Projects\TestSymbolServer\bin\Release\TestSymbolServer.pdb" -i:srcsrv -s:"C:\Users\mb\Documents\Visual Studio 2010\Projects\TestSymbolServer\bin\Release\symbols.txt"
I getting only this response:
C:\Users\mb\Documents\Visual Studio 2010\Projects\TestSymbolServer\bin\Release>p
dbstr -w -p:"C:\Users\mb\Documents\Visual Studio 2010\Projects\TestSymbolServer\
bin\Release\TestSymbolServer.pdb" -i:srcsrv -s:"C:\Users\mb\Documents\Visual Stu
dio 2010\Projects\TestSymbolServer\bin\Release\symbols.txt"
pdbstr -r/w -p:PdbFileName -i:StreamFileName -s:StreamName
When I check pdb with srctool I can see that nothing was written. And moreover- I'm getting the same response when I try to read stream from the pdb like this
"C:\Program Files\Debugging Tools for Windows (x64)\srcsrv\pdbstr" -r -p:"C:\Users\mb\Documents\Visual Studio 2010\Projects\TestSymbolServer\bin\Release\TestSymbolServer.pdb" -i:srcsrv
Could this be an issue with pdbstr or in my environment? Can I somehow get logs from pdbstr?
My laziness is appeared to be the root of all evil.
I have added "C:\Program Files\Debugging Tools for Windows (x64)\srcsrv" to system path variables and run pdbstr from folder were my local project resides. Looks like pdbstr has some dependencies in install folder.
So it should be called from the original location.
Short path long problems list :-(
Related
Actually, I'm trying to add new language to Streama Media Server. I downloaded source code, added new language file (as guided here). After that, I want to build a jar with that project, I build it with IntelliJ Idea 2021.1 (here is how I did). So, When I run that jar file (in Ubunt 20.04), it fails and gives this error: Screenshot
When you have made adjustments to the source code, it is likely that you will want to create a new .jar file and deploy it on your server. For this, you can use a simple command:
# for unix based systems
**./gradlew assemble**
# for windows
**./gradlew.bat assemble**
This will create 2 new .jar files under build/libs,
streama-{version}.jar
streama-{version}.jar.original
all you will need is the streama-{version}.jar.
This file is an executable, so you can just copy it into your deployment directory / your server and start it as usual.
My build completes with no errors, but it creates a randomly named zip file (s.zip) for the release step.
After the release step, I end up with that s.zip in inetpub/wwwroot/admin-tool/ folder. I'm almost there, but I want it to unzip and dump all the contents in here. This should be automatic, shouldn't it?
My dotnet publish looks like this:
and cause this to run, which is how I get the s.zip:
C:\Program Files\dotnet\dotnet.exe publish C:\agent\_work\3\s\Angular.AdminTool.csproj -c release --output C:\agent\_work\3\a\s
If I try to edit the -o argument and make it -o $(Build.ArtifactStagingDirectory)/admin-tool I will just end up with C:\agent\_work\3\a\admin-tool\s.zip
Is getting the name of my zip to be the same as the name of my web-site (admin-tool) the key to getting the zip to automatically extract in the release step?
In case it help others, I used the simple command line tools rather than the pre-canned "dotnet core" ones:
and for the Archive files task, be sure to include a hard-coded name for the zip to be used in the build process:
And for the release, in the "Deploy IIS App" task, be sure to include the full path for the zip file:
I also ran into this issue but solved it another way.
In my case I have a single project to build and deploy.
The $(Parameters.RestoreBuildProjects) value is set to a single project
MyProjectFolder/MyProject.csproj.
In the .Net Core Publish task, this value is used in the Path to Project(s) field.
Then I tick both the boxes for
I saved and queued this pipeline.
The zip file created seems to be derived from the name of the folder
so I ended up with a zip file in the artifact staging directory with the name of the project. Then the Publish Artifact task placed this zip file into the Artifact that is named in that task.
I have an archiving script that uses 7z -tzip -aoa and it runs on unix and works fine. But when run through Autosys, it always fails when trying to archive a second file to an existing archive. The error is:
7-Zip 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=C,Utf16=off,HugeFiles=on,8 CPUs)
Scanning
Updating archive
20150807.zip
Error:
7-Zip cannot open file
20150807.zip.tmp
Permission denied
It doesn't tell me where it's having permissions with that tmp file, so I don't know where to look. I've set all the permissions to any folders that I thought it might be using to 777, but the problem persists. It works great when not using Autosys.
I found the comment below but it seems to be relevant only to Windows. I'd like to know how I can make this work on UNIX.
I tried to search for a while on the net, but couldn't find any help, so here I am.
My first problem is when I try to compress a folder in C:// with the context menus (7-zip > Add to "xyz.zip"), I get the error : "Access is denied. 7-zip cannot open file "xyz.zip.tmp"
I can however open the file manager in the 7-zip folder ("7zFM"), run as administrator and compress the said file to .zip.
It seems to be a security issue about C:// directory, since it seems that I can compress other files and folders just fine.
Any help?
Link
Shell
Shell
2012-07-29
You have guessed right. You can either 1) run 7-Zip as administrator or 2) set the working directory in 7-Zip File Manager (Tools->Options->Folders) to an unprotected one (for example, clear the checkbox there) and use the "Add to archive…" menu and create the archive in an unprotected directory.
Set the working directory using the -w switch.
7z does not use current directory (the one you get by pwd) as a working directory. It uses the one that the resulting archive is going to be created at.
For example:
/tmp $ 7z a /folder.7z /folder
will ignore the fact you're in /tmp and will first create a tmp file in / and then put the result in the / no matter what you current folder is.
If you don't have access to create files in / but you do have access to update the archive that's already there (a very valid scenario) you're going to get exactly what you get:
/tmp $ 7z a /folder.7z /folder
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.utf8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i7-7500U CPU # 2.70GHz (806E9),ASM,AES-NI)
Open archive: /folder.7z
--
Path = /folder.7z
Type = 7z
Physical Size = 150
Headers Size = 150
Solid = -
Blocks = 0
Scanning the drive:
1 folder, 2 files, 0 bytes
Updating archive: /folder.7z
Items to compress: 3
Error:
cannot open file
/folder.7z.tmp
Permission denied
System ERROR:
Unknown error -2147024883
Also, in case you're omitting the archive name from the command line, it's going to use directory of your source.
For example, when you do this:
7z a /folder
it is going to use / as a working directory - it will attempt to create temp file in / and will put the resulting archive there as well.
To fix that just make sure that the archive name is in your command line and that you have file create permission to the folder the archive is going to be created (sometimes you have access to update the archive itself but can't create new files in the dame folder)
I am trying to publish an ASP.NET web site project using the Publish Web Site tool but get this error:
ASPNETCOMPILER(0,0): Error ASPRUNTIME: The specified path, file name,
or both are too long. The fully qualified file name must be less than
260 characters, and the directory name must be less than 248
characters.
I see that it is trying to copy the files to a very long path in AppData:
Copying all files to temporary location below for package/publish:
C:\Users\imx0\AppData\Local\Temp\1\WebSitePublish\BMW.Web-424993535\obj\Debug\AspnetCompileMerge\Source.
c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /BMW.Web -p C:\Users\imx0\AppData\Local\Temp\1\WebSitePublish\BMW.Web-424993535\obj\Debug\AspnetCompileMerge\Source C:\Users\imx0\AppData\Local\Temp\1\WebSitePublish\BMW.Web-424993535\obj\Debug\AspnetCompileMerge\TempBuildDir
I couldn't find anything about this temp directory in my .pubxml publish profile. How can I change the temporary directory that Visual Studio copies the files to?
Add this to your publish profile to modify the temporary directory for package/publish:
<AspnetCompileMergeIntermediateOutputPath>c:\shortPath\</AspnetCompileMergeIntermediateOutputPath>
Go to your web project folder, navigate to Properties\PublishProfiles folder.
open your profile file profile_name.pubxml (not the profile_name.pubxml.user)
copy/past <AspnetCompileMergeIntermediateOutputPath>c:\shortPath\</AspnetCompileMergeIntermediateOutputPath> under the <PropertyGroup> tag
save your file, you would be able to publish your website using this profil
This is sort of an aside answer, but I ran into this problem when trying to MSBuild a solution that depended on nodeJS and gulp. The problem was that the gulp dependency tree became very deep and the aspnet_compiler was trying to copy that tree to a deeper directory, resulting in this error. I tried everything noted in here but nothing worked.
As it so happened, I was building with TFS, so my solution was to run an attrib +h node_modules\* /S /D before msbuild to hide the directory tree and then attrib +h node_modules\* /S /D. That did it for me.
Sure would be nice if the error thrown in this situation by the compiler revealed the path that caused the write to fail...
try adding this
<IntermediateOutputPath>..\Temp</IntermediateOutputPath>
to the default <propertyGroup />
None of the other answers worked for me.
Visual Studio 2013 Community Edition.
I changed the TMP and TEMP environment variable to a short folder name and it worked.
We identified the lengthy files/folders using this solution, then corrected the issue from there:
Run this script at the command prompt: dir /s /b | sort /r /+261 > out.txt it will output all file paths into the out.txt file
Copy the output to an Excel file
In the next column over from what you pasted in add this Excel function: =LEN(A1) where "A1" is the cell, copy this against every file length so you can see how long the paths are
Sort in Excel by the path length
Identify the lengths over the recommended limit
I know this is a bit long-winded but if you have several files that are resulting in this issue you'll be able to see them all.
Even though the content of node_modules was not included in neither version control not in the *.csprojfile itself Deleting the whole node_modules folder did the trick for me.
You can try the selected solution for correcting the long file path issue.
Still if not able to publish due to some other issue, You can try below method.
=> If the 'Solution Configuration' is in 'Debug' mode, please change the same to 'Release' mode and Publish the files.
=> If the Solution Configuration is in Release mode, and if the problem still persists, please try to delete the dll generated earlier in the 'Release' folder of our project and Publish the project once again.
Any of the above method will solve the issue.
For me, using Visual Studio 2019, the only change to the publish profile .pubxml file that worked was:
<WPPAllFilesInSingleFolder>c:\shortPath\</WPPAllFilesInSingleFolder>
I discovered this property at line 484 of Microsoft.Web.Publishing.targets file. Full path was C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\v16.0\Web.
I have a website project, and an outlook addin that communicates via a webservice to the same database. I'd like to add the outlook addin as "downloadable file" to the interface of the website.
How to achieve that at build time the outlook addin installer ends up in the website's "Download" folder?
Is that possible?
Thanks in advance!
I am not sure this is really a good idea, because maybe not every time you build it it is ok to upload it (broken builds? untested bugs?), but anyway, the idea might be this:
find a way to mount the FTP site mounted as disk Z in the computer and keep it there
you probably want to zip it before, so find and install a command line zip.exe
find a way to have an automated job start every few minutes (like a batch file)
The job (might be a batch file) should do this:
check the file creation date of C:\build\folder\executable.exe and compare it with the file creation date of Z:\download\folder\executable.zip
only if newer, zip C:\build\folder\executable.exe to C:\build\folder\executable.zip and copy C:\build\folder\executable.zip to Z:\download\folder\executable.zip
In what language you write the script is your choice, a windows batch could do (the XCOPY command can copy only newer files), I know PHP and probably would use that with a batch file calling "php my_php_task.php", but you can launch any language interpreter you like.
UPDATE
For zipping you can download this:
http://www.info-zip.org/Zip.html
For copying only newer files u can use XCOPY with options /D (newer only) and /Y (confirm overwriting). Other options here:
http://www.computerhope.com/xcopyhlp.htm
So the batch file might look just similar to these two lines:
zip -f C:\build\folder\executable.zip C:\build\folder\executable.exe
xcopy /D /Y C:\build\folder\executable.zip Z:\download\folder\executable.zip
Have it called every 30 seconds and the job is done. The -f option in zip and /D option in xcopy make sure the script does nothing except check creation dates if you have not recently rebuilt the file.