Can I create a 'Python Distribution' with my module directly using PTVS(Python Tools for Visual Studio) ? I have done this before using command line but not using PTVS. If yes, how ?
Thanks!
Currently no. I think the feature you'd like to vote on is Feature: build package. If you've done this with py2exe or other packages in the past then you could wire this directly into PTVS with our 2.1 release. This will give you a context menu on your project which will let you run the command from within the IDE.
To do this you'd modify your .pyproj file and add something like:
<PropertyGroup>
<PythonCommands>$(PythonCommands);PythonRunPyLintCommand</PythonCommands>
<PyLintWarningRegex>
<![CDATA[^(?<filename>.+?)\((?<line>\d+),(?<column>\d+)\): warning (?<msg_id>.+?): (?<message>.+?)$]]>
</PyLintWarningRegex>
</PropertyGroup>
<Target Name="PythonRunPyLintCommand"
Label="Run PyLint"
DependsOnTargets="ResolveStartupPath"
Returns="#(Commands)">
<CreatePythonCommandItem Target="pylint.lint"
TargetType="module"
Arguments=""--msg-template={abspath}({line},{column}): warning {msg_id}: {msg}" -r n #(Compile, ' ')"
WorkingDirectory="$(WorkingDirectory)"
ExecuteIn="output"
RequiredPackages="pylint>=1.0.0"
WarningRegex="$(PyLintWarningRegex)">
<Output TaskParameter="Command" ItemName="Commands" />
</CreatePythonCommandItem>
</Target>
This example is shelling out to PyLint but you can change TargetType to executable/script/code or pip to execute different things. And you can change ExecuteIn to console, output, or repl to have the output show up in various different locations.
Related
I get "Sharing violation on path" error whenever I try to build a VS project on macOS if the project is not in Users/../projects folder. I keep my work files on separate drive (exFat) which is perfectly accessable and works fine both under windows and macOS.
I assume it happens because of some permissions' violation but I am very new to macOS and can't figure it out.
macOS version - Mojave
Fixed in the way like kinhoon said, thanks.
One useful side note: we can use "Home" env variable instead of hardcoded users/<user_id> folder
<IntermediateOutputPath Condition=" '$(OS)' == 'Unix' ">$(Home)\path_to_folder\$(Platform)\$(Configuration)</IntermediateOutputPath>
Looks like it's a bug related to the way OS or VS handles writing on file systems FAT and exFAT.
https://www.feval.ca/posts/fixing-cs2012/#fn:1
I found another solution, which you can still keep your code in exFAT.
https://xamarin.github.io/bugzilla-archives/15/15093/bug.html
The solution in the above link suggests to manually edit the project file and put the following line into the build configuration to put the intermediate files in your Mac volume:
<IntermediateOutputPath Condition=" '$(OS)' == 'Unix' ">\Users\your_user_id\path_to_folder\$(Platform)\$(Configuration)</IntermediateOutputPath>
Note that you need to replace your_user_id and path_to_folder in the line above with your own values specific to your Mac installation.
The best is to put the line in every platform and configuration.
You can actually put it somewhere other then Users folder, but that seems to be the best place to put.
Can't get the simplest .Net Core 2.0 console app to run on my macOS High Sierra.
As per the Get started instructions, I created and tried to run the simplest app from Terminal:
dotnet new console -o myApp
cd myApp
dotnet run
The result is the error:
A fatal error was encountered. The library 'libhostpolicy.dylib' required to execute the application was not found in '/Users/xyz/Projects/myApp/bin/Debug/netcoreapp2.0/'
Surprisingly, the /bin/Debug/netcoreapp2.0 folder contains the files React.dll and React.pdb
The applications runs properly from within VS Code and VS 2017, but not from terminal.
Any idea why those React files are there and why the app doesn't run from Terminal?
Info
myApp.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
myApp.runtimeconfig.json
{
"runtimeOptions": {
"tfm": "netcoreapp2.0",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "2.0.0"
}
}
}
Not exactly sure what happened but the problem seems to have disappeared after a reboot.
I strongly suspect that the problem was related to the global environmental variable (TARGETNAME), as explained here. In fact React.dll was the actual output of the build process and not just an unwanted dependency.
I am still puzzled as to why rebooting fixed the issue, since I had already tried closing and reopening terminal several times with no success.
I'm rebuilding my xampp and CI environment (on win7) from scratch but am having trouble running phpdoc through phing. In particular, Phing is looking to phpdocumentor.ini in a place that doesn't exist (and never has).
Phing and PhpDocumentor have both been installed through Pear, paths setup seems fine, and have these versions:
php version 5.4.7
pear version 1.9.4
phpdoc version 2.0.1
phing version 2.6.1
Relevant paths on the system are:
H:\xampp\php;
H:\xampp\php\pear;
On my sample project:
I can run phpdoc without a hitch, for example: phpdoc -d apps -t docs runs fine.
Here's my phpdoc task, which has worked well in the past:
<phpdoc title=Docs" destdir="${docsdir}" sourcecode="false" output="HTML:frames:earthli">
<fileset dir="./apps">
<include name="**/*.php" />
</fileset>
<projdocfileset dir=".">
<include name="README" />
<include name="INSTALL" />
<include name="CHANGELOG" />
</projdocfileset>
</phpdoc>
When I run Phing, phpdoc fails with the following notice:
Parsing configuration file phpDocumentor.ini...
(found in C:\php\pear\data/PhpDocumentor/)...
ERROR: cannot open phpDocumentor.ini in directory
-Is phpdoc in either the path or include_path in your php.ini file?
There is no c:\php... directory, and never has been, so I don't know where this has come from.
I can only get this working if I create the whole PHPDocumentor structure Phing anticipates on C: but I'd ideally like to get the ini file's anticipated location changed so I have everything on the one drive.
Is there any way I can inform Phing of the true location of my phpdocumentor.ini?
I've not found this specific problem listed on SO, but am hopeful someone else has seen and rectified this. The Phing site docs/forum/trac don't list any recent reports of this problem.
Thanks all
It looks like you're trying to use phpDocumentor 2.x and seeing some behavior from what looks like phpDocumentor 1.x. Perhaps there is some 1.x code that came with the XAMPP source that is lingering and affecting your ability to run 2.x cleanly.
In considering the Phing angle, in glancing at the Phing manual, it looks like the correct Phing task to use for phpDocumentor 2.x is the DocBlox task [1] rather than the old PhpDoc task.
[1] -- http://www.phing.info/docs/guide/stable/apcs52.html.
Downloading the latest zip archive release of XAMPP for Windows I see that the file:
\xampp\php\pear\PhpDocumentor\phpDocumentor\Setup.inc.php
the function parseIni() refers directly to the aforementioned path:
enter code herephpDocumentor_out(" (found in " . 'C:\php\pear\data/PhpDocumentor' . PATH_DELIMITER . ")...\n");
So its more likely to be a XAMPP problem than any of the components I've been upgrading or force-reinstalling.
I am using a SQL 2008 database project (in visual studio) to manage the schema and initial test data for my project. The atabase project uses a post deployment which includes a number of other scripts using SQLCMD's ":r " syntax.
I would like to be able to conditionally include certain files based on a SQLCMD variable. This will allow me to run the project several times with our nightly build to setup various version of the database with different configurations of the data (for a multi-tenant system).
I have tried the following:
IF ('$(ConfigSetting)' = 'Configuration1')
BEGIN
print 'inserting specific configuration'
:r .\Configuration1\Data.sql
END
ELSE
BEGIN
print 'inserting generic data'
:r .\GenericConfiguration\Data.sql
END
But I get a compilation error:
SQL01260: A fatal parser error occurred: Script.PostDeployment.sql
Has anyone seen this error or managed to configure their postdeployment script to be flexible in this way? Or am I going about this in the wrong way completely?
Thanks,
Rob
P.S. I've also tried changing this around so that the path to the file is a variable, similar to this post. But this gives me an error saying that the path is incorrect.
UPDATE
I've now discovered that the if/else syntax above doesn't work for me because some of my linked scripts require a GO statement. Essentially the :r just imports the scripts inline, so this becomes invalid sytax.
If you need a GO statement in the linked scripts (as I do) then there isn't any easy way around this, I ended up creating several post deployment scripts and then changing my project to overwrite the main post depeployment script at build time depending on the build configuration. This is now doing what I need, but it seems like there should be an easier way!
For anyone needing the same thing - I found this post useful
So in my project I have the following post deployment files:
Script.PostDeployment.sql (empty file which will be replaced)
Default.Script.PostDeployment.sql (links to scripts needed for standard data config)
Configuration1.Script.PostDeployment.sql (links to scripts needed for a specific data config)
I then added the following to the end of the project file (right click to unload and then right click edit):
<Target Name="BeforeBuild">
<Message Text="Copy files task running for configuration: $(Configuration)" Importance="high" />
<Copy Condition=" '$(Configuration)' == 'Release' " SourceFiles="Scripts\Post-Deployment\Default.Script.PostDeployment.sql" DestinationFiles="Scripts\Post-Deployment\Script.PostDeployment.sql" OverwriteReadOnlyFiles="true" />
<Copy Condition=" '$(Configuration)' == 'Debug' " SourceFiles="Scripts\Post-Deployment\Default.Script.PostDeployment.sql" DestinationFiles="Scripts\Post-Deployment\Script.PostDeployment.sql" OverwriteReadOnlyFiles="true" />
<Copy Condition=" '$(Configuration)' == 'Configuration1' " SourceFiles="Scripts\Post-Deployment\Configuration1.Script.PostDeployment.sql" DestinationFiles="Scripts\Post-Deployment\Script.PostDeployment.sql" OverwriteReadOnlyFiles="true" />
</Target>
Finally, you will need to setup matching build configurations in the solution.
Also, for anyone trying other work arounds, I also tried the following without any luck:
Creating a post build event to copy the files instead of having to hack the project file XML. i couldn't get this to work because I couldn't form the correct path to the post deployment script file. This connect issue describes the problem
Using variables for the script path to pass to the :r command. But I came across several errors with this approach.
I managed to work around the problem using the noexec method.
So, instead of this:
IF ('$(ConfigSetting)' = 'Configuration1')
BEGIN
print 'inserting specific configuration'
:r .\Configuration1\Data.sql
END
I reversed the conditional and set NOEXEC ON to skip over the imported statement(s) thusly:
IF ('$(ConfigSetting)' <> 'Configuration1')
SET NOEXEC ON
:r .\Configuration1\Data.sql
SET NOEXEC OFF
Make sure you turn it back off if you want to execute any subsequent statements.
Here's how I am handling conditional deployment within the post deployment process to deploy test data for the Debug but not Release configuration.
First, in solution explorer, open the project properties folder, and right-click to add a new SqlCmd.variables file.
Name the file Debug.sqlcmdvars.
Within the file, add your custom variables, and then add a final variable called $(BuildConfiguration), and set the value to Debug.
Repeat the process to create a Release.sqlcmdvars, setting the $(BuildConfiguration) to Release.
Now, configure your configurations:
Open up the project properties page to the Deploy tab.
On the top dropdown, set the configuration to be Debug.
On the bottom dropdown, (Sql command variables), set the file to Properties\Debug.sqlcmdvars.
Repeat for Release as:
On the top dropdown, set the configuration to be Release.
On the bottom dropdown, (Sql command variables), set the file to Properties\Release.sqlcmdvars.
Now, within your Script.PostDeployment.sql file, you can specify conditional logic such as:
IF 'Debug' = '$(BuildConfiguration)'
BEGIN
PRINT '***** Creating Test Data for Debug configuration *****';
:r .\TestData\TestData.sql
END
In solution explorer, right click on the top level solution and open Configuration Manager. You can specify which configuration is active for your build.
You can also specify the configuration on the MSBUILD.EXE command line.
There you go- now your developer builds have test data, but not your release build!
As Rob worked out, GO statements aren't allowed in the linked SQL scripts as this would nest it within the BEGIN/END statements.
However, I have a different solution to his - if possible, remove any GO statements from the referenced scripts, and put a single one after the END statement:
IF '$(DeployTestData)' = 'True'
BEGIN
:r .\TestData\Data.sql
END
GO -- moved from Data.sql
Note that I've also created a new variable in my sqlcmdvars file called $(DeployTestData) which allows me to turn on/off test script deployment.
I found a hack from an MSDN blog which worked fairly well. The trick is to write the commands to a temp script file and then execute that script instead. Basically the equivalent of dynamic SQL for SQLCMD.
-- Helper newline variable
:setvar CRLF "CHAR(13) + CHAR(10)"
GO
-- Redirect output to the TempScript.sql file
:OUT $(TEMP)\TempScript.sql
IF ('$(ConfigSetting)' = 'Configuration1')
BEGIN
PRINT 'print ''inserting specific configuration'';' + $(CRLF)
PRINT ':r .\Configuration1\Data.sql' + $(CRLF)
END
ELSE
BEGIN
PRINT 'print ''inserting generic data'';' + $(CRLF)
PRINT ':r .\GenericConfiguration\Data.sql' + $(CRLF)
END
GO
-- Change output to stdout
:OUT stdout
-- Now execute the generated script
:r $(TEMP)\TempScript.sql
GO
The TempScript.sql file will then contain either:
print 'inserting specific configuration';
:r .\Configuration1\Data.sql
or
print 'inserting generic data';
:r .\GenericConfiguration\Data.sql
depending on the value of $(ConfigSetting) and there will be no problems with GO statements etc. when it is executed.
I was inspired by Rob Bird's solution. However, I am simply using the Build Events to replace the post deployment scripts based on the selected build configuration.
I have one empty "dummy" post deployment script.
I set up a pre-build event to replace this "dummy" file based on the selected build configuration (see attached picture).
I set up a post-build event to place the "dummy" file back after the build has finished (see attached picture). The reason is that I do not want to generate changes in the change control after the build.
I just upgraded a project from 2008 to 2010 Beta 2 and StyleCop is now reporting SA1305 (Hungarian notation) warnings on variable names with the prefix 'is'. 'Is' is definitely in the list of allowed prefixes.
Is this a known issue? Has anyone else run across this problem? The code was definitely compiling without any warnings in 2008.
Update: It turns out that this can work as expected in Visual Studio, but then fail through MSBuild. See the answer below for why.
You can manually add the "is" exception to Settings.StyleCop:
<Analyzers>
<Analyzer AnalyzerId="Microsoft.StyleCop.CSharp.NamingRules">
<AnalyzerSettings>
<CollectionProperty Name="Hungarian">
<Value>is</Value>
</CollectionProperty>
</AnalyzerSettings>
</Analyzer>
</Analyzers>
I ran across a similar issue now when building with msbuild vs on a developer box. It turns out that the default Settings.StyleCop (C:\Program Files (x86)\MSBuild\Microsoft\StyleCop\v4.4) that is installed actually contains a bunch of values you will need to duplicate in your own file if either:
you are not installing StyleCop on the "other" (build) machine
or
you have "do not merge with any other settings files" enabled
Specifically - the StyleCop Settings Editor picks up the Hungarian notation excludes from the other file automatically, regardless of what the "Settings Files" tab says.
just add it like this:
<Analyzer AnalyzerId="Microsoft.StyleCop.CSharp.NamingRules">
<AnalyzerSettings>
<CollectionProperty Name="Hungarian">
<Value>is</Value>
</CollectionProperty>
</AnalyzerSettings>
</Analyzer>
http://www.thewayithink.co.uk/stylecop/sa1305.htm