SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: jporkkahtc on November 14, 2019, 09:17:19 PM
-
When you create a VS2017 .net framework project, then do Add Existing Item, and in the file dialog you select "Link", VS2017 adds the following to an <ItemGroup>
<Compile Include="..\..\common\MyProgram.cs">
<Link>common\MyProgram.cs</Link>
</Compile>
This works in Slickedit.
But, when you create a .NET core project in VS2017, and do the same thing for a link VS2017 inserts this:
<Compile Include="..\..\common\MyProgram.cs" Link="common\MyProgram.cs" />
Slickedit doesn't recognize this :-(
As far as Visual Studio is concerned, they are equivalent.
https://community.slickedit.com/index.php/topic,17201.msg66784.html#msg66784
-
Hm... nope - it isn't the <Link> thing that is the problem.
I changed them all to the old style, and still Slick doesn't recognize these.
It seems to only recognize all source files at or beneath the project.
I'm still trying to figure this out.
-
OK, so a netcore csproj looks like:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<RootNamespace>sample1._0</RootNamespace>
</PropertyGroup>
<ItemGroup>
<Compile
Include="..\..\..\build\project\src\name.space\**\*.cs"
LinkBase="Build"/>
</ItemGroup>
</Project>
Slick edit doesn't seem to like having files outside of the project dir:
<ItemGroup>
<Compile Include="..\common\FooBar.cs"><Link>Common\FooBar.cs</Link>
</Compile>
</ItemGroup>
There is also a thing "LinkBase"
<ItemGroup>
<Compile
Include="..\..\..\build\project\src\name.space\**\*.cs"
LinkBase="Build"/>
</ItemGroup>
See also: https://github.com/dotnet/sdk/pull/1246
For traditional framework projects, I followed information from here: https://stackoverflow.com/questions/4623304/can-i-use-both-wildcard-and-link-element-inside-the-compile-element
and did this:
<ItemGroup>
<Compile Include="..\..\..\..\build\project\src\name.space\Dir1\*.cs" Link="Build\Dir1\Placeholder.cs" />
</ItemGroup>
That works in VStudio and Slickedit.
It doesn't work in netcore project files though.
Anyways, Linkbase seems to be the best way to go.
-
Looking into this
-
I'm not sure I'm seeing what you are seeing.
SlickEdit seems to list the files in all cases I tested but doesn't get the folders correct in a number of cases.
Anything with a wildcard, doesn't seem to support Link or LinkBase by any means (attribute or element).
This doesn't work for me (file listed by not in folder specify) because a wildcard is specified.
<ItemGroup>
<Compile Include="..\..\..\..\build\project\src\name.space\Dir1\*.cs" Link="Build\Dir1\Placeholder.cs" />
</ItemGroup>
-
I'm still experimenting with it. (I've been trying to convert some non-trivial projects from .net framework to .net core).
Yesterday most of the time, Slick wasn't getting those wildcards, then by the end of the day it was.
I'm not sure whats going on with it.
Once case it surely doesn't handle is paths with properties:
<ItemGroup>
<Compile Include="$(SOMEWHERE)\src\name.space\Dir1\*.cs" />
</ItemGroup>
I've also noticed that with just a simple project where it is supposed to take in all files recursively from the project down, it is also pulling in some temporary files.
I've found bugs in VisualStudio 2017 - it definitely gets confused sometimes when you edit the project - I've had to restart it to get it working right.
-
The code for pulling in files underneath the project is tricky. Not surprised it's picking up extra files. If you can post a sample toy project, I'll investigate and see if we can reasonable exclude those files.
It looks like wildcards should always work. It just won't put them into a custom folder you've specified. I can easily make improvements for non-wildcards supporting Link/LinkBase better. I'll have to investigate the custom folders (Link/LinkBase) for wildcards more.
-
If you have a sample where SlickEdit is listing extra files (not excluding temp files), please post a sample project.
I've got it supporting a lot more. Added support for the different forms for Link/LinkBase (attribute or element). I've also added some fixes for wildcards. Wildcards now support Link/LinkBase. There also was a bug where wildcard files were being listed in the Projects tool window but not anywhere else (i.e Project>Open Files From Workspace). This means tagging wasn't working and neither was smart open.
SlickEdit still doesn't fully support Link but I don't think anyone will care. SlickEdit just treats Link as if it's a LinkBase (strips the name part off).
These fixes will be in 24.0.1
-
I was going to report the problem with the opentool, but you found it!.
One example extra file that shows up: *.vpj files.
Other things:
PackageReference items show up in the ProjectWindow as files.
<ItemGroup><PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.4.0" /></ItemGroup>
In a *.pyproj InterpreterReference items also show in the project window:
<ItemGroup> <InterpreterReference Include="Global|PythonCore|3.7" /> </ItemGroup>
-
Thanks.
I've added excludes for *.vpj, *.vpw, and *.vtg
Also skip PackageReference and InterpreterReference includes.
-
Just installed hotfix 5, thanks!
Also, #1
<ItemGroup>
<WCFMetadata Include="Connected Services\" />
</ItemGroup>
Results in an empty item in the projects tool.
#2 In my CSProj there is:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
In the "Class" tool there is an entry for this line.
Double clicking it, I get the error
---------------------------
SlickEdit Pro
---------------------------
Tag 'Condition=" '$' not found.
---------------------------
OK
---------------------------
-
Please upload/post a small sample solution/project?
Thanks
-
I uploaded a sample to support.
-
Thanks for the sample. I fixed problem #1 by just ignoring WCMFMetadata so its' not process.
The second issue is interesting. Nothing to do with Visual Studio solutions. There seems to be a general problem with the Class tool window and XML files. You can navigate to elements but not attributes. I'm not sure if this is a limitation or a bug. We will look into this.
Here's a trivial sample XML file which can illustrate the problem:
<project>
<aaa aaavalue="aaavalue"/>
<bbb bbbvalue="bbbvalue"/>
</project>
-
This lil' old XML bug will be fixed in 24.0.1. Good catch, but not worth hot-fixing.