| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
All services are now referenced from the IdeServices class
|
|
The old autotools build infrastructure is largely redundant,
as projects are now built with msbuild. Remove as much as can
be done easily, along with some other obsolete stuff.
|
|
NuGet's PrivateAssets="runtime" does not work, resulting in transitive
references local copying their assemblies into every project. This
works around that by filtering out all local copies that are not
explictly listed.
This also makes it much harder to accidentally introduce local copies,
which is good as local copies in general are are not desirable due to
the way that dlls are loaded by the extension system.
|
|
|
|
|
|
These all have some kind of custom NuGet asset copying step
that will require additional logic.
|
|
|
|
|
|
|
|
|
|
Remove redundant information, and make more information
redundant by setting good defaults in the MD props.
This lays some groundwork for the PackageConfig migration
and eventually SDK-style project format migration.
|
|
|
|
|
|
|
|
|
|
This breaks compiling MonoDevelop when both gtk# 2.0 and 3.0 are installed in the GAC.
Always reference the strong named version and remove SpecificVersion=false
|
|
Fixed bug #56625 - T4 editor breaks - no syntax highlighting and
typing issues
https://bugzilla.xamarin.com/show_bug.cgi?id=56625
Creating a new T4 file from the template would result in the file
having duplicate byte order marks at the start. Deleting characters
from the file in the text editor would then have odd behaviour where
some of the characters were not removed. The problem was that the file
templates had a byte order mark in the CDATA section which was causing
the duplicate byte order marks in the created .tt file.
|
|
|
|
MonoDevelop.AspNet. (#2160)"
It causes the build to always be dirty, and it's not necessary as the
TextTemplating assembly is signed.
This reverts commit 1393fee6068c9a34988f5c0d5a2f05ac4a4c2bc3.
|
|
typing issues'
The old syntax mode wasn't used. We had T4 textmate highlighting the
syntax mode was just bad/not working.
|
|
This way that the reference Mono.TextTemplating.dll is automatically signed when copied to output directory.
This fixes bug https://bugzilla.xamarin.com/show_bug.cgi?id=54679 where MonoDevelop crashes with:
Could not load file or assembly 'Mono.TextTemplating, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)
|
|
|
|
|
|
# Conflicts:
# main/external/debugger-libs
# main/src/addins/MonoDevelop.DotNetCore/MonoDevelop.DotNetCore.csproj
# main/src/addins/MonoDevelop.Refactoring/MonoDevelop.CodeActions/CodeActionEditorExtension.cs
# main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.csproj
# main/src/core/MonoDevelop.Ide/packages.config
# version-checks
|
|
|
|
Problem started with ca287231cfe2d12 where I required resolving of full path of assembly to be able to remove duplicates by comparing FullName of assembly. Which works fine in case of running inside IDE but when TextTransform.exe is used engine doesn’t resolve to full path but leaves GAC assemblies unresolved, which is OK since compiler can resolve this just fine later in process.
|
|
|
|
We had 3 different cases of completion - the c# binding already
contained a solution for that : completion trigger info. That struct
contains all information the backend needs to take care of.
|
|
Roslyn 2.x needs this so we have to do it for MonoDevelop.Core
and every assembly that references it.
|
|
|
|
|
|
syntax highlighting'
Added new extension point '/MonoDevelop/SourceEditor2/Bundles' - it's
now possible to throw all stuff of textmate/sublime3 extensions in
there. The old one was just for syntax modes.
|
|
|
|
reference not set to an instance of an object
|
|
|
|
|
|
|
|
|
|
This removes substring calls that allocate strings so chars are copied
from offsets into the stringbuilder.
|
|
of the ProjectFile.Project
When files are removed from a project, ProjectFile.Project is null. We
can use the value of project from the event args instead.
Fixes bug #42345
|
|
On Windows using a full path when creating an AssemblyName throws a
FileLoadException - 'The given assembly name or codebase was invalid.'
When resolving assembly references if the path is a full path then
the DummyTemplateGenerator now just returns the path. Fixing this then
caused the template code generation to fail with two compiler errors:
warning CS2023: Ignoring /noconfig option because it was specified in
a response file
error CS1703: An assembly with the same identity 'System,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' has
already been imported. Try removing one of the duplicate references.
By removing the .dll part from the assembly reference the System.dll
is now correctly resolved so no duplicate System assembly is added.
This fixes the compiler errors.
|
|
TemplateGeneratorTest
|
|
reference not set to an instance of an object
ProjectFileTemplatingHost.cs:
Replacing properties like $(SolutionDir) with correct value when resolving assembly path(https://msdn.microsoft.com/en-us/library/bb126478.aspx#Anchor_3)
MonoDevelopTemplatingHost.cs:
Apperently it's legal to say "System.dll" in T4, which GAC lookup doesn't like
TemplatingEngine.cs:
/noconfig is needed so mcs.exe(or csc.exe) doesn't report error CS1703(An assembly `System' with the same identity has already been imported. Consider removing one of the references) for System.dll
TemplateGenerator.cs:
By adding reference by FullName we let framework resolve full path, which allows deduplication of System.dll reference in case when user also specifies <#@ assembly name="System.dll" #>
|
|
|
|
And add tests and parsing API.
|
|
|
|
|
|
|
